Javabeans for dummies

What are Javabeans Components: Self-sustained object(s) Providing standard services for the builder Visual Customizabillity! Providing those standard services is what makes a piece of Java code a Javabean “We start to describe javabean components on a high level without going into implementation details” “It is just a standard coding style” (well sortof)

JavaBeans Goal Create applications by using 3rd party Beans Customize 3rd party beans Connect those beans Also the abillity to program your own Beans Interact with 3rd party beans Which can be used and customized by other Javabean devellopers Extend 3rd party beans with extra functionallity Give some simple examples of simple trivial programs and their even more trivial components. NOTE: Making your own beans is a just java programming

Customizing Javabean components Builder tools: Customize components (and save them) Couple components via events Construct entire applications Example using JBeanSDK The Java BeanBox is a Javabean itself BeanBox is a test-container NOT a full blown builder! Show some of the features of Javabeans, using JBeanSDK Beanbox TESTCONTAINER I actually first assumed the beanbox was the builder application itself, but was very dissapointed with its features. Luckilly I have found the real builder now

Javabeans services How are these implemented? Events Properties Introspection Customization (uses Properties) Persistance Set of methods for others to call “There must be a way to provide services like: ... + reason” VIA (empty) INTERFACES/ design patterns/ Serialization must be mentioned!: Persistance

Why provide these services? Builder tools needs ways to: Customize beans Connect beans To build applications using a builder: With a builder and many 3rd party JavaBeans. Things you can’t find elsewhere you’ll have to make yourself Link between services: and what features they provide (this sheet is a little redundant)

How does the builder know? How to extract properties and methods? Introspection: Getter and setter methods (simple) “Method pattern” Implementing BeanInfo interface “Java reflection service” Builder will use any interface it comes across when inspecting beans Explain difference between the two methods of propery/method extraction!

Method patterns explained public java.awt.Color getBackground( ); public void setBackground( java.awt.Color ); private java.awt.Color Background; ---------------------------------------------------------- public <PropertyType>get<PropertyName>( ); public void set<PropertyName>( <PropertyType> a ); private <PropertyType> PropertyName; How specific method patterns are used by Builders to detect which properties are available; (introspection is used) Minor disadvantage; one must use those specific names for methods. Not really object oriented approach. (Beaninfo is more object related)

Method patterns continued Can also get/set multiple items at once public java.awt.Color getSpectrum( int index ); public java.awt.Color[] getSpectrum( ); ------------------------------------------------------------------------ public void setSpectrum( int index, java.awt.Color color ); public void setSpectrum( java.awt.Color[] colors );

Implementing BeanInfo In short: Beaninfo has a collection of abstract classes Those classes must be implemented in such a way that: They give away the events that the object can send They tell about the properties that can be set/get/bound Abstract example: public Vector getEvents( ) public Vector getProperties( ) public .... Builders look for implementations of certain INTERFACES so if it finds BeanInfo for instance it knows what functions to expect EXAMPLES ARE NOT REAL! just abstracted for easy storytelling

Properties in detail Property getters/setters Property binding: whatever the method used (design patterns or implementing beaninfo) Property binding: Vetoability class: Other objects can overrule a propery change if they are registered to have veto over such property

Property binding If a beans properties are changed it is possible another bean want to act on that change Examples: Colorscheme: backgroundColor changes for all objects Disabling buttons: just one of a set of buttons needs to be disabled for the rest to be disabled too Take the colorscheme example; to direct the entire code based explaination that follows

Scenario: Color scheme Try to imagine this is a monitor screen (sortof) The screen Background is white There is a RED graphic with a blue button on it The other buttons are also blue All buttons must adhere to the color scheme; so if the background changes to for example green: the buttons turn RED But the lowerright button DOES NOT WANT TO TURN RED::: because you cannot see it anymore

Property binding implementation Source object additions (screen background): private PropertyChangeSupport changes = new PropertyChangeSupport( this ); public void addPropertyChangeListener( PropertyChangeListener l ) { changes.addPropertyChangeListener( l ); }; public void removeProperyChangeListener( PropertyChangeListener l) { changes.removePropertyChangeListener( l ); Can be done in different ways: Some builders uses a method similar to this one; but differs in precise implementations

Property binding implementation 2 Source Object “additions”: public void setBackgroundColor( java.awt.Color Color newColor ) { java.awt.Color oldColor = backgroundColor; backgroundColor = newColor; changes.firePropertyChange(backgroundColor, oldColor, newColor ); }; We only add a fire event at the end of our set routine

Property binding: PropertyChangeSupport class firePropertyChange: public void firePropertyChange( string propertyName, Object oldValue, Object newValue ); This predefined method calls all registered change listeners

Property listeners So firePropertyEvent calls the listeners: how do listeners look like? Property change listeners implement the interface: “PropertyChangeListener” Has only 1 method: public abstract void propertyChange( PropertyChangeEvent evt ); Please note that: the listener is mostly implemented in another object that is interested in this ‘event’

Property listeners 2 public class someButtonThatAlsoWantsToChangeColor implements java.beans.PropertyChangeListener { public void propertyChange( PropertyChangeEvent evt ) // code here setBackgroundColor( inverse(evt.Color) ); }; Mostly the target listener will just do the same as the Source of the changed property eg: change it’s color too

Property vetoabillity Before a bean property changes: other beans might want to stop that change Button does not like color RED Background wants to turn RED Button.color is bound to Backgroundcolor The button shouts: “NOOOOOOOOOO!” throw PropertyVetoException

Scenario: Color scheme (again) Try to imagine this is a monitor screen (sortof) The screen Background is white There is a RED graphic with a blue button on it The other buttons are also blue All buttons must adhere to the color scheme; so if the background changes to for example green: the buttons turn RED But the lowerright button DOES NOT WANT TO TURN RED::: because you cannot see it anymore

Property veto implementation private VetoableChangeSupport vetos = new VetoableChangeSupport(this); public void addVetoableChangeListener( VetoableChangeListener l ) { vetos.addVetoableChangeListener( l ); }; public void removeVetoableChangeListener( VetoableChangeListener l ) { vetos.removeVetoableChangeListener( l ); } ; So the ‘screen’ has an object to maintain a list of VetoListeners Same way as with the PropertyChanges

Property veto implementation 2 public void setBackgroundColor( java.awt.Color Color newColor ) { java.awt.Color oldColor = backgroundColor; vetos.fireVetoableChange( “backgroundColor”, new java.awt.Color( oldColor ), new java.awt.Color( newColor ) ); backgroundColor = newColor; changes.firePropertyChange(backgroundColor, oldColor, newColor ); }; First check for vetos: if none of the listeners vetoed: Do change; and notify all changeListeners

Vetos: fireVetoableChange fireVetoableChange calls all registered veto listeners Those listeners implement the vetoableListener interface This interface has the method: public abstract void vetoableChange( VetoableChangeEvent evt ) throws PropertyVetoException

Property veto implemtation 3 Back to our button that doesn’t like “RED” public class someButtonThatAlsoWantsToChangeColorAndDoesNotLikeRed implements java.beans.PropertyChangeListener implements java.beans.VetoableChangeListener { public void propertyChange( PropertyChangeEvent evt ); public void vetoableChange( VetoableChangeEvent evt ) throws PropertyVetoException if( evt.id = “BackgroundColor” && evt.newColor == “RED” ) throw PropertyVetoExeption; // Pseudocode }; NOTE: there can be more than 1 condition where we want to throw exceptions: all implemented in same function

How does the builder know? How events are extracted: Builder looks for implemented interfaces: BeanInfo Method patterns: public void add<ListenerType>(<ListenerType>Listener I) public void remove<Name>Listener(<ListenerType>Listener I) Same method as property events are passed bounds vetos

Event Communication in detail The source: Provides add and removeListener functions Provides a set of interfaces that must be used by potential listeners The source signals the event: And sends all listeners a notification Every event will go to all listeners Every listener checks what Event it was and reacts accordingly

Event Source interface UserSleepsListener extends java.util.EventListener { public abstract void UserSleeps( UserSleepsEvent e ); }; class Source { public void addUserSleepsListener( UserSleepsListener I ); public void removeUserSleepsListener( UserSleepsListener I ) throws java.util.TooManyListenersExeption; private Vector listeners = new Vector( ); TooManyListenersException can be used to keep the event Unicast instead of Multicast Unicast :: only 1 listener per event Multicast :: more listeners can get notified about this event NOTE: the fact add<UserSleepsListeners>; and UserSleepsListeners is a extension of EventListener; The builder therefor knows about this object as an event source.

Event Source signals Events like a OnMouseClick in class Source protectec void OnMouseClick ( Point cor, int button ) { Vector tempListeners; EventObject e = new EventObject; synchronized( this ) { tempListeners = ( Vector )listeners.clone( ); } for( int i = 0; i < tempListeners.size( ); i++ ) ( (UserSleepsListener )tempListeners.elementAt( i ) ).UserSleeps(e); };

Event Listeners buttonOK does something on recieving event UserSleeps class buttonOK implements UserSleepsListener { public void UserSleeps( UserSleepsEvent e ) // code here }; buttonOK does something on recieving event UserSleeps

Event adapters When an event listener, recieves the same event from 2 or more different objects Traditional method: Checking needs to be done in the listener Code will get less readable Event Adapter construction: Checking done seperately in adapter class Every source 1 Adapter Adapter maintains lists of Listeners (reg and unreg methods) Beware: Class explosion Examples? or example code;? I Prefer a nice diagram/picture

Multi-Sourced Events ::Traditional:: class buttonOK implements UserSleepsListener { public void UserSleeps( UserSleepsEvent e ) if( eventSourceChecker( e ) == “screen” ) { UserSleepsA(e) }; if( eventSourceChecker( e ) == “buttonCancel” ) { do skip }; if( eventSourceChecker( e ) == “picture1” ) {UserSleepsB(e) }; if( eventSourceChecker( e ) == “sliderUp” ) {UserSleepsC(e) }; }; public void UserSleepsA( UserSleepsEvent e ) {//code}; public void UserSleepsB( UserSleepsEvent e ) {//code}; public void UserSleepsC( UserSleepsEvent e ) {//code} ; Event sources can be determined using reflection in Java

Multi-Sourced Events ::Adapters:: class AdapterButtonOK_A implements UserSleepsListener { public void UserSleeps( UserSleepsEvent e ) { for( int i=0; i < listeners.size(); i++ ) { listener.ElementAt(i).UserSleepsA( e ); // ..other checking code... }; private Vector listeners = new Vector( ); // reg+ unreg methods Other adapters: AdapterButtonOK_B, AdapterButtonOK_C We just replace the code and put it into the Adapter The adapter then calls the appropiate methods in the listeners The adapter must be able to register and unregister Listeners

Muli-Sourced Events ::Adapters:: 2 class buttonOK { public void UserSleepsA( UserSleepsEvent e ) {//code}; public void UserSleepsB( UserSleepsEvent e ) {//code}; public void UserSleepsC( UserSleepsEvent e ) {//code} ; }; buttonOK now just implements funtionality and does not need to check for event origin Because each different source has its own adapter The universal UserSleeps Adapter will be seen in the example

Adapter examples 1

Adapter examples 2

Adapter examples 3

Adapter examples 4