240 likes | 329 Views
Lecture 5. Serialization in greater detail The new FrameEditorDemo Javadoc comments Java UI Managers, PLAF JDesktopPane. Serializing example. // In actionPerformed(ActionEvent e) method. // code handles “Save” menuitem by storing a // serialized object to file.
E N D
Lecture 5 • Serialization in greater detail • The new FrameEditorDemo • Javadoc comments • Java UI Managers, PLAF • JDesktopPane
Serializing example // In actionPerformed(ActionEvent e) method. // code handles “Save” menuitem by storing a // serialized object to file. if (e.getActionCommand().equals("Save")) { try { FileOutputStream out = new FileOutputStream(fname); ObjectOutputStream s = new ObjectOutputStream(out); s.writeObject(mySerializableObject); s.flush(); } catch (Exception ex) { System.out.println("Save exception."); ex.printStackTrace(); }
What is written: • Class identification information • A unique identifier (called the SUID) • Serialized contents of each field. • Recursive. Not tricked by reference loops. • Includes even private and static fields • Excludes transient and non-Serializable fields. • May generate NotSerializableExceptions.
Why isn’t Class X Serializable? • Class declared abstract or final. No way to instantiate such a class, which is what de-serialization does. • Special/Secure classes like RunTime, System, ClassLoader • Classes which depend essentially on other non-Serializable classes. • javax.swing.plaf.ComponentUI?
NotSerializableExceptions • Suppose A is Serializable and B is a subclass of A. Then B inherits the Serializable interface and can’t get rid of it. The only way to prevent serialization is to throw an Exception. • Several Swing components do this. Their behavior is too closely tied to non-Serializable PLAF components.
Custom Serialization • Method 1: Declare as transient all fields which you do not want to serialize. Must declare all Serializable fields which would generate an Exception. • Method 2: Add custom methods: • writeObject() etc. • Method 3: throw NotSer…Exception.
Custom Serialization II • Traps: references to exception-throwers may be hidden (private fields of ancestor classes: addActionListener) or unexpected (JMenuBar creates a exception-throwing PopUpMenuUI when it is clicked on.) They may also be important; in this case, you may not want to implement Serializable.The Runtime Object
New FrameEditorDemo • Arranged in packages. • Sample targetFrame (SquarePuzzleApp) doesn’t throw exceptions anymore. • Doesn’t try to serialize menus or ActionListeners anymore. • ActionListeners are handled directly by the SquarePuzzleApp, not by Jbuttons now.
Editor Saver Register ActionEvents SquarePuzzleApp JButton JButton Before
Editor Saver Register SquarePuzzleApp JButton JButton After Relayed ActionEvent ActionEvents
Editor Saver SquarePuzzleApp JButton JButton The Point Throw Exceptions This relationship is transient (but easily reinstated) IsAn Action Listener Serializable View Code
Javadoc • Automatic API generation system. • By default, generates a frame-based class and package website. Can be customized to produce other formats than HTML. • Generates docs from specially formatted comments. Should have one for each field and method of each class.
Doc Comments • A doc comment is made up of two parts -- a description followed by zero or more tags, with a blank line (containing a single asterisk "*") between these two sections: /** * This is the description part. It can * be any number of lines. * * @tag Comment for the tag */
Javadoc Markup • Any HTML (carefully), esp. <p> • @author, @version • @param, @return • @deprecated, @throws • @serial • {@link}, @see
Running Javadoc • javadoc packagenames sourcenames • Either: run javadoc from parent directory of source tree or type absolute pathnames for packages and sources. • Ex: javadoc docdemo or javadoc C:\files\desktop\Demo\DD\docdemo • Leave html files in same directory structure.
The JDesktopPane class • Parent JLayeredPane. Can hold multiple overlapping internal frames. • Internal frames may be dragged, resized, iconified. These events are handled by a DesktopManager object. • Demo
JDesktopPane Pro & Con • Gives more control over window behavior than JFrames. Can control minimization, window look and feel. • Appearance same on all platforms, easily configurable. • Requires more management. Can’t just add components without saying where. Minimization prefs.
Extra Fields in JInternalFrame • closable, closed, desktopIcon, desktopPane, frameIcon, icon, iconifiable, layer, layeredPane, maximizable, maximum, resizable, selected
Pluggable Look and Feel ‘The JFC Swing UI building blocks are designed around a Pluggable Look and Feel architecture that allows us for the first time to get away from interpreting the visual manifestations, and instead “plug in” a non-visual manifestation. This architecture separates the expression of the UI from the underlying structure and data on a component-by-component basis.
Pluggable Look and Feel This is accomplished by separating the user interface of the component from the “model” of the component (the structure which encapsulates the state and information that the user interface portion presents to the user).’
PLAF: advantages • Better platform independence. Mac users automatically get Mac L&F, PC users get Windows L&F, etc. • Accessibility. Specialized L&F can present in braille or audio output which was not specially formatted for this purpose. • Convenience. UI easier to write.
PLAF: how? • Each Swing component has 5 objects needed to make it pluggable. • Component itself (e.g. button) • API for the buttonUI • A default implementation buttonUI • API for a Button model • A default implementation: JButton
Using the UIManager • UIManager.setLookAndFeel(LNF) changes the default L&F for new components. UIManager.getblahblahLookAndFeelClassName() can be used as an argument to this call. • SwingUtilities.updateComponentTreeUI(frame); updates L&F for existing frame • frame.pack() resizes & draws the frame.
Course Project • First Checkpoint is next Friday…one every week.