1. Javabeans
for dummies

2. 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)

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

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

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

6. 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)

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

8. 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)

9. 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 );

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

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

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

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

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

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

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

17. 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’

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

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

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

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

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

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

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

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

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

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

28. 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); };

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

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

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

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

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

34. Adapter examples 1

35. Adapter examples 2

36. Adapter examples 3

37. Adapter examples 4