Skip to main content

Swing Frameworks and Best Practices

9 replies [Last post]
majeric
Offline
Joined: 2003-06-13
Points: 0

HOLY COW! I have considerable google-fu powers and so I spent a more than my fair share of hours looking for Swing Best Practices and/or Frameworks.

I *am* simply stunned by all the great components people are developing and all of the interesting exporation into XML generated GUIs. It's Great! However the lack of the basics is equally stunningly frustrating? You wonder why there are no Java Desktop applications? No one seems to know how to design one.

I mean the idea was to find a means by which to structure my Swing applications that makes sense; is clean and tidy; and is scalable. A "This is how I build my Swing Applications" type document/discussion.

I was also interested in what sort of Application Frameworks exist for Swing. Someone who'd done a little high level development such that everyone doesn't have to write an application from scratch.

So I searched. I looked into ever facet of Swing Development I could get my hangs on. The following is just a fraction of a hair of the searching that I did but they are the most telling results:

Google Searches:
"Swing Best Practices" - 34 hits
"Swing Application Framework" - 205 hits
"Designing Swing Applications" - 28 hits

I mean one really basic question I have is that I have a great little application interface that I've developed and I've got "business logic model" that hooks into that interface and then I would like to use XML as my means of persisting that logic model.

The interface consists of a few panels of collections of widgets like tables and text fields that the user fills out, the "business model" is suppose to be a reflection of what's in the UI.

Now in the case of Tables and Trees, they have a great Model abstraction interface that you can apply to your business model. Sweet, done.... but what about my text fields? It seems to me that they lack that ability ot set a model object. Is it just me, or is the MVC not extended to all the component widgets?

Now what about persisting my "logic model" to XML? I want my XML to be readable so the actual XML Object persistence tools seem a little over kill. I'm just writing XML some simple XML. So, how *do* you hook a DOM into a business logic model.

Now I thought about Aspect-Oriented Design. I mean persistence is a "cross cutting concern" it seems? but I imagine that is equally overkill.

There are a *few* great Swing Application out there... but most of my friends laugh at me when I suggest that Swing has great potential to be as powerful as a lot of the native applications we see on our desktops.

I want *someone* to say "Hey, this is how I think swing applications should be structured". They don't have to be right... but born from this is the possibility that everyone will start expressing their option on the subject.

I'm starting to form an opinion but I'm working on my *first* swing application framework so once it's done, I'll come back and put my money where my mouth is...

In the meanwhile? Anyone want to take the challenge?

I throw down the gauntlet!

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
john_roshi
Offline
Joined: 2008-02-20
Points: 0

Maybe this is an attempt?

https://appframework.dev.java.net/

astast69
Offline
Joined: 2006-03-22
Points: 0

The problem
============
I agree with you Majeric. It’s very hard to find good documentation about "real" application. All you have is a lot of code snippets from java-api-doc or from forums. Mostly about cool things like a moving java-Duke or something.

And written material is hard to use, since the platforms change every odd year. I have put three java books in the trash since they describe old techniques and now I don't bother buying them. And you can't trust thing on the net to be up to date.

It would be nice if each new java-release had an example-swing-application. With all the basic component a modern user expect of a professional application and nothing else. And nice if that application could have some basic architecture. And, please, no IDE-specific code or feature in it.

Real Application
============
What you need is guidelines and practice about building a real application.

A real application has almost no "cool" things. It has main-class, login dialog, menu, toolbar, statusbar, user-preferences, configurations, aboutdialog, and similar-looking dialogs and panels.

Every thing is localized, logged, configurable, and rock-solid error handling (which is easy to understand tor an enduser).

Each table shall be sortable and you shall be able to view/hide different columns. And when you restart the application the table shall be configured the same and it was when you shut down the application.

And it shall be maintainable. If the users want e.g. a different color on "Ok"-buttons (used in 100 places) the fix shall take, 5 minutes, not 5 days. So you cant just paint all gui in a java ide, you have to have some base-component/classes.

My applications
============
I have worked with large swing applications since mid-90’s. I have developed my own best practice. I can't spread them, not documented enough and other companies have the rights.

I use my own gui common lib. It has classes both to use insert directly in a panel and other more architectural.

One of my hardest architect problems to design is actions. They are called from menu, popup menus, toolbar and buttons. And in different states they are to be greyed out correctly. And it shall be easy to find the code called from the action (to maintain the code).

I tend to use a lot of singletons, sometimes because there is a nice access (getInstance) to them. ActionHandler, SelectionHandler, UserPreferrences, InternationisationHandler, ViewHandler, MainFrameHolder, BusinessFunctionHolder, TopologyHandler, CommunicationHandler, ErrorHandler.

The Singletons and the Gui common lib above are the basics of the Application, then you have to fill it out with tons of dialogues, panels, data classes hopefully divided in nice named package.

And for layout, I love the DynamicGridLayout (look at the net). It can layout almost all real problems and it’s very easy to use and maintain.

majeric
Offline
Joined: 2003-06-13
Points: 0

Wow, I didn't realise this thread still had life.

I've love to see s suite of open source applications that were tailored for their platforms with a minimum amount of change. I am starting to see some good examples but I'm surprised that people still haven't written a basic RTF editor.

Utlimately people seem more interested in buildng clever components for Swing than they are in building clever applications that use those components.

I'm holding out... in the meanwhile. I am working on my own. They will be under cider.sourceforge.net once I've got at least one working example.

Cheers,
Jeremy

stacktrayce
Offline
Joined: 2006-08-09
Points: 0

I was about to start a new thread but then I found this old one, maybe it will become active again :)
Anyway, I am looking at some of these same issues and trying to come up with a recommended way of separating control logic, GUI and data structures from one another in our projects.

I don't quite like the idea of making all my data structures extend Observable as there is often already a hierarchy of inheritance already in place. Is the best way to go about this wrapping a data structure in an Observable or having a State backing object contain an observable object tied to a ds object? Is using Observer/Observable even still considered the best practice for good swing architecture?

I had found the Fowler references on my own and it is good to see them referenced again. I will be reading through those tomorrow. I also found an interesting idea using the new Java 5 annotations to define mappings and introducing a dispatcher component:
http://www.javaworld.com/javaworld/jw-10-2005/jw-1003-mvc.html

I looked at swixat which uses XML to describe views and don't think that will work for my needs because I will just end up fighting it when I need to create custom components.

Anyway, maybe other people could chime in with their ideas or new links.

dshmif
Offline
Joined: 2003-06-16
Points: 0

There's a book coming out by Scott Delap that looks promising called 'Desktop Java Live'. Can't say I know off hand the release date. He runs clientjava.com which is another great source of information.

karsten
Offline
Joined: 2003-06-11
Points: 0

Hello,

I've been writing Swing apps for several years that many people find elegant.
And I teach developers in working with Swing efficiently: how to structure
and assemble applications, how to bind and validate date, as well as how to
find, design, layout, and implement well-designed screens in Swing.

I'd say there are no "best practices" for Swing available online. And I
doubt that anyone can provide "best" practices, because that would require
discussions among Swing developers and solution providers about approaches,
what works well technically and what is easy to understand, and work with.
Also, best practices would explain who can achieve what result quality,
and they would describe the production time and production costs;
but I could never find these information online or in a Swing book.

In my opinion, the lack of good practices and information how to build
a Swing app is the biggest obstacle developers face when starting with Swing.
Most developers I worked with were slow in finding design, implementing layouts,
building panels, binding data, handling events, and arranging the different code
parts and code layers. And many Swing apps I've seen suck; besides their poor
visual design they are difficult to understand and even small changes costs a lot.
Typically developers had no clue where to put what code?, how to separate concerns?,
how to tie things together?, how to work with Actions?, how to launch an app?,
and how to store and restore UI state? Most developers lack guidelines to follow.

But I've found that the average developer can work well with Swing, if only
taken by the hand - in about 3 to 10 days. Almost all of your questions can be
answered or addressed by code, libraries, the application architecture, patterns,
general programming practices, well-designed examples, tutorials, etc.
I teach a Swing development process that is built around a 3-tier architecture
that seperates the domain, tool and presentation layers and that is based on
a productive layout system. Even though most parts are done programmatically
developers get results quickly and both the code and visual design becomes
quite consistent. This can boost a developer's productivity a lot - to the extent
that the Swing work takes a significantly smaller fraction of the project work.

So what can you do? I strongly recommend to study Martin Fowler's draft
for further "Patterns of Enterprise Application Architecture". I've found
that these patterns work really well with Swing and Swing teams - even for
developers that are new to Swing and the Swing architecture. I'd pick
the following patterns first: "Presentation Model", "Separated Domain",
and "Separated Presentation". I personally favor the Presentation Model
(Application Model for Smalltalkers), over the Model-View-Presenter
pattern (MVP). However, MVP is a true and well studied alternative.

Fowler's patterns can be combined with a 3-client-tier architecture
that scales well for moderately large Swing applications. It consists of
a domain layer, a presentation layer, and a mediating model layer.
I've outlined this architecture in my data binding presentation.
MVP-based apps can be structured in these 3 client tiers too.

A key task for Swing applications is the data binding: how to connect
domain objects and domain object properties to the Swing components.
Basically you can copy your data back and forth, or build chains of
adapters from your domain objects to the UI components. The copying
approach is easy to understand and often the first choice for those
who are new to Swing or data binding; I'd say this is a good choice.
On the other hand, copying makes it much harder to synchronize views.
Adapter chains and automatic or semi-automatic updates can significantly
reduce the amount of code necessary to bind domain data to the UI.
The downside is, that this approach is much harder to understand.
As you've pointed out, Swing provides no great abstraction for a
reusable and flexible model that can be used to bind text fields;
the Document interface isn't appropriate for generic data access.
There are a few libraries available that provide a ValueModel interface
that is just intended to add a generic, powerful, and flexible model
for single-valued data: Strings, booleans, numbers, dates, etc.

I'm not aware of a Swing book that explains a true Swing application
development process. Ideally such a book would combine the patterns,
architecture, and data binding techniques mentioned above and would
describe how to implement it in Swing. Anyway, there's a 10-years old
documentation for a Smalltalk application development process
that does just that. Oracle's JClient architecture and documentation
is not that complete but may be easier to read for Java developers.
I provide a presentation about data binding that is about the
Fowler patterns, a 3-tier architecture and a Swing implementation
for these patterns and an automatic data binding. The tutorial
sources of my Binding library may help you get aquainted with
adapter chains and the ValueModel interface. The best documentation
for the MVP pattern can be found in the Dolphin Smalltalk docs.

Once you've choosen your architecture and desktop pattern set,
you should address the following more basic Swing tasks:
1) improve the appearance by choosing a set of professional
look&feels appropriate for your target platform set,
2) choose a layout system that helps you build well designed
and consistent screens quickly,
3) choose a data validation solution, and
4) grab a bag of solutions for everyday Swing tasks.

There are a couple of projects that outline a Swing architecture,
address the data binding and typical Swing tasks, for example:
Sun's JDNC, Oracle's JClient/ADF, the Spring RCP, the NetBeans
platform. I provide a commercial suite of Swing solutions that
is based on the open source JGoodies libraries and adds a bag
of solutions and sources for all public JGoodies tools and demos.
These sources are intended to explain how to tie together all issues
mentioned above.

Let me add my standard warning about so called "MVC" frameworks.
Swing doesn't use MVC, it uses a modified pattern. MVC is frequently
misquoted and misunderstood - especially in the context of Swing.
Also, MVC is good for UI components, not for applications.
Hence I recommend to look for concepts, solutions, and libraries
that reflect and work with the Swing architecture, not MVC.

The inventor community of the MVC pattern introduced the ApplicationModel
(now known as Presentation Model) around 1993; MVP followed a bit later.
In my opinion these two patterns are much more useful for Swing than MVC.
Recently the environment that brought the Presentation Model pattern
to a larger audience moved on to a new architecture: "Pollock".
Interested readers may google to see how that differs from the
adapter chains that are often combined with Presentation Models.

Last but not least a personal statement. I can work much better
with Swing than with other toolkits or frameworks I used before;
I can do more with less code, the code is better structured, it's
easier to maintain, and I get results quickly.

Hope this helps. Best regards,
Karsten Lentzsch

References:
Fowler's further patterns - http://martinfowler.com/eaaDev
Data binding presentation - http://www.jgoodies.com/articles/
Smalltalk app dev process - http://www.cincom.com/downloads/pdf/AppDevGuide.pdf
MVP pattern documentation - http://www.object-arts.com/EducationCentre/Patterns/MVP.htm
Sun's JDNC project home - http://jdnc.dev.java.net/
Oracle's ADF FAQ - http://www.oracle.com/technology/products/jdev/htdocs/905/adffaq_otn.html
Spring RCP project home - http://www.springframework.org/spring-rcp.html
NetBeans platform home - http://www.netbeans.org/products/platform/
JGoodies Swing Suite - http://www.jgoodies.com/products/index.html

zander
Offline
Joined: 2003-06-13
Points: 0

> I mean one really basic question I have is that I
> have a great little application interface that I've
> developed and I've got "business logic model" that
> hooks into that interface and then I would like to
> use XML as my means of persisting that logic model.
>
> The interface consists of a few panels of collections
> of widgets like tables and text fields that the user
> fills out, the "business model" is suppose to be a
> reflection of what's in the UI.

You will not find many frameworks like that since this is a really bad way to design an application. It all looks great for the programmer until you show it to users and usability experts and get flamed down. Truth is that business models just never map to UIs at all. You need to provide a manually created UI enough times to not bother with any XML or other mapping framework.

> I want *someone* to say "Hey, this is how I think
> swing applications should be structured". They don't
> have to be right... but born from this is the
> possibility that everyone will start expressing their
> option on the subject.

I did a lot of this in my pet project (which is open source) it contains things like a MainWindow to get people started.
The usage of them is wide, though, so you won't find any guidance on how to structure your classes and UIs at all.
Best practices are like opinions, you get the longest lasting (and most usefull) ones from experience.
Unfortunately, just like opinions, they can cause lots of arguments when printed as truth, so I mostly refrain from doing so :)

majeric
Offline
Joined: 2003-06-13
Points: 0

> Best practices are like opinions, you get the longest
> lasting (and most usefull) ones from experience.
> Unfortunately, just like opinions, they can cause
> lots of arguments when printed as truth, so I mostly
> refrain from doing so :)

Zander, that's my point! I want someone to express an opinion. I want as many people as I can find to express an opinion on this subject! Because when we share our ideas we can blend them and mutate them and mix them up and then come up with a few more ideas... and we take away from it the best bits that we like and we create our own ideas and what evolves out of it are a great collection of Best Practices.

What I don't want is a few people to have some clever ideas and then not share them. Because then Java as a desktop environment will *NEVER* take off... and quite frankly, Swing's been on the runway for a while now.

Jeremy

zander
Offline
Joined: 2003-06-13
Points: 0

> > Best practices are like opinions, you get the longest
> > lasting (and most usefull) ones from experience.
> > Unfortunately, just like opinions, they can cause
> > lots of arguments when printed as truth, so I mostly
> > refrain from doing so :)
>
>
> Zander, that's my point! I want someone to express an
> opinion. I want as many people as I can find to
> express an opinion on this subject!

As an open source developer I express most of my ideas in my designs which you can find on my site http://uic.sf.net and the codebase behind it.

I (for example) implemented a SwingWorker replacement that makes the SwingWorker look like a hack in that my solution incorporates actions, threading options and lots of other goodies.
Please just read the site, download the latest sources and/or drop in on the mailinglist if you have any questions.