Posted by alexfromsun
on March 2, 2009 at 12:02 PM PST
Long-awaited update of Swing Application Framework status
I know this is not good to disappear for a long time from blogging and SAF mail aliases, I am sorry about that. This happened because Swing team had some urgent temporary tasks to work on. The good news is that most of the tasks are completed and Swing team has returned to its primary goal - Swing library.
I should say that this time I have really come back to SAF and this project is currently #1 priority for the Swing team. We organized a little team to move SAF further and now working on schedule. My team mates asked me what problems with the current SAF code come to my head straightway and how I envision the "ideal Swing Application Framework".
This blog is written to start the conversation about those issues, it is intended not only for my colleagues but for all Swing programmers who are very welcome to comment.
The "singleton problem"
Static method Application.launch() saves the current application instance to the static field and returns it with Application.getInstance()
This prevents using Application inside one JVM but from different AppContexts. Imagine that two applets on the same html page launch an applicaiton, they will likely to be run inside one JVM so they will share static data of any class, so an applet can't use static Applicaiton.getInstance() to access to its own application instance.
Design of the View class
Let's look at the the class' javadoc:
* A View encapsulates a top-level Application GUI component, like a JFrame
* or an Applet, and its main GUI elements: a menu bar, tool bar, component,
* and a status bar. All of the elements are optional (although a View without
* a main component would be unusual).
Class View has methods like getMenuBar()/setMenuBar(), getToolBar()/setToolbar() and getRootPane().
This works fine for a MDI applicaiton where each view is operated by its own frame and each frame can have its own menu bar. This is exactly like most of the native application on Windows or *nix work.
However a good framework must support SDI applications as well, on Mac OS all application's view shares one menu bar and it is better to let the view customize the "main" menu bar rather than having one menu bar per a view. It is also not unusual for a Mac application to have a "view" with a menu bar but with no main component.
SingleFrameApplication is bound with JFrame.
A good framework should be friendly with IDE, let's say I want to build a SingleFrameApplication in my favorite IDE designer. In this case I shouldn't explicitly use classes like JFrame or JDialog because it is very difficult for an IDE to control and design a real JFrame.
Applets is the more obvious example, it should be as easy to run a SingleFrameApplication as an applet as a standalone application.
The common pattern here is to provide all the data that required to build a JFrame but don't explicitly create it. It will allow the different view containers to show the view in a different way.
Lack of flexible menu support
I am not a Mac user, so I was really impressed when I knew how difficult it is to make a Swing application look like native on Mac.
The menu bar is one of the main issue, it is totally different on Mac, please see this article for details. There is no need to say that SAF should automatically solve this kind of problems.
The ideal framework
It is small but very flexible, any part of its functionality can be easily overridden. For example, if you don't like the implementation of LocalStorage, it is easy to plug in your own implementation. It is free from all mentioned problem and knows how an application should look like on a particular OS.
The question of the day
I mentioned only a few problems with the current SAF to start a discussion. What do you think about the problems I mentioned and what is your list of features that SAF must have?
note: don't forget that SAF is supposed to be a small framework.
I am looking forward for your comments
It won't take a half a year for the next blog, I promise.