:: JGOODIES :: UI Framework

:: Guide :: How to Use ::

This text explains how you can use the framework and benefit from its content.

Learn about Problems

The UIF addresses a couple of problems you face when developing and running a Swing application. Being aware of these problems is the first step to solving them.

For example, a well designed application stores and restores its window bounds. You can check the list of problems and learn that it is a good idea to persist these bounds. You may then look for a solution for incorporation into your applications.

Another way of becoming aware of problems and tasks is to run the JGoodies tools and demos. You may have noticed that Skeleton Pro restores its windows bounds.

Check out Concepts

You can study the list of solutions that describes how we address the problems mentioned before. You can learn how we've separated concerns: which class is responsible for setting and limiting the bounds, which class provides the initial state, which class talks to the persistency mechanism, and that there's a library for user preferences.

And if you look at the Skeleton Pro sources you'll see that the application stores and restores general application state - not only the windows bounds, but also the view layout and application settings.

Use the UIF Sources

You can now pick the concepts that apply to your projects and use our code as starting point for your custom solution. You can copy, extend and modify our sources and move it to your code base.

For example you may use our AbstractFrame class that persists bounds and modify the backing store: where we use a backport of the J2SE 1.4 preferences, you may wish to use the 1.4 code.

Use the UIF Binaries

If you are fine with our implementations or have no Swing code basis, you can just go ahead and use the unmodified UIF binaries. At any time if you feel a need to extend or modify a given UIF solution, you can replace our binary class with your modified source version.

About final Markers

Many UIF classes have been marked as final to better ensure binary compatibility between updates and upgrades. As an alternative, we could precisely describe the contract we're implementing. For example this has done well in the Java Collection classes. But the latter approach takes a lot of time. Also, we've found that many developers ignore contracts that are defined in the documentation only.

In this tradeoff we've decided to mark classes as final if we cannot foresee their future use. You may at any time remove the final marker and extend classes and even modify our code.

(c) 2008 JGoodies