:: 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.
|