Introduction to Java Beans

1. Introduction to Java Beans CIS 421 Web-based Java Programming

2. Components • Components are : 1. self-contained, 2. reusable software units that can be visually composed into 1. composite components, 2. applets, and 3. applications using visual application builder tools.

3. What are Component Models? • Component Models are the next step in object-oriented programming • Component Models allow us to: • Create objects as components • Customize a component • Introspect a component • Interact with other components • Build other higher level components

4. Desirable Properties of Components • A component should: • be modular • follow object oriented principles • be “plug & play” • be generic so that it can be used in different scenarios.

5. Java & Components Java is a good platform for component technology because: • It is object-oriented • It provides applets that run on a web server. • It has platform independence. • It has basic features like multi threading, security, etc. • It has features to communicate with remote objects. • It is able to furnish info on class contents at run-time.

6. Java Beans • A Java Bean is a reusable software component that can be manipulated visually in a builder tool • BeanBox is a simple tool • Note: Not all beans are visual beans.

7. Java Beans contd.. Features that distinguish a Java Bean from Java objects are: • introspection • customization • externally occurringevents • properties • persistence

8. Java Beans contd.. • A bean is not required to inherit from any particular base class or interface. • Visual beans inherit from java.awt.Component. • Though Beans are primarily targeted at builder tools, they are also entirely usable by human programmers. • Beans are more than class libraries. • ordinarily stored in jar files

9. Properties, Methods and Events • Properties are the named attributes associated with a bean. • Methods of a Bean are the normal Java methods which can be called from other components. • Events are a way of providing information to other components by notifying them about something which happened.

10. Design Time Vs. Run Time Design Environment • Provides Information used by builder tool to customize the appearance and behavior of Beans. Run-time Environment • Provides information for other beans as well as applications to use it. Java Beans API allows design time interfaces to be separated from run-time interfaces.

11. Java Features used in Beans • Beans can be stored and retrieved for a later use by implementing Java’s Serializable interface. • Remote Invocation • Java RMI provides a facility for remote Beans to communicate with each other. • JDBC Connectivity • JDBC provides a means to store Beans in a database.

12. Java Features used in Beans contd.. • JAR Utility • Used for packaging beans • AWT and Swing • All visible beans are made from AWT or Swing components. • Beans use event handling of AWT. • Reflection • Used to know about the beans at run-time. • Security - Beans follows the same security model of Java.

13. Design Pattern • Beans follow strict design patterns. • Design pattern helps IDEs to detect various state variables for configuration and editing. • The common design patterns are: • Set / Get methods for properties • Add / Remove methods for events

14. Event-driven Designs Handling user interface events : -Mouse Actions -Keyboard events Managing / reporting inter-client connections. Other events: • Property changes in a bean • Any general-purpose notification

15. Delegation Event Model • Based on publish and subscribe system . • Objects that provide events are called publishers or sources. • Objects that subscribe, and can receive events, are listeners or targets. • Sources fire events and listeners wait for event to be fired on them.

16. Delegation Event Model [1]contd.. Public synchronized FooListener addFooListener (FooListener fel) Register Listener Event Listener fire Event FooEvent Event Source eListener Class fooey implements FooListner { Void fooBarHappened (FooEvent fe) { } } Interface reference

17. Event Handling in AWT • A listener object is an instance of a class that implements a special interface called listener interface. • An event source is an object that can register listener objects and send them event objects. • addActionListener(this) • The event source sends out event objects to all registered listeners when that event occurs. • The listener objects will then use the information in the event object to determine their reaction to the event.

18. Java Event Libraries • java.util.eventObject • java.awt.event • java.awt.dnd • javax.swing.event

19. Types of Events • Low-level events: • Tied to GUI component like focus, click, key-pressed, etc. • Semantic events:Used in a higher level where the user can customize the way of representing event.

20. Low-level Events EventObject CompoentEvent FocusEvent InputEvent MouseEvent

21. Semantic Events ActionEvent ItemEvent AdjustmentEvent

22. Event Sources • Sources are the objects which fire events. • Sources maintain a list of listeners. • keep track of added listeners • Listeners can register and unregister themselves with a source. • Listener registration methods are prepended by add and remove. Event Listeners • waits for events. • Listener names end with Listener

23. User-defined events? • Custom Events: • Can create and define events. • User defined event objects extend the EventObject class.

24. Event Delivery • Events can be delivered as either unicast or multicast. • Unicast – Only one listener possible. • Throws ToomanyListenersException • Multicast – Many listeners possible.

25. Adding an Event to the Bean • Create EventListener class. • Create EventListener objects in the bean. • Register the EventListener objects with Swing or AWT components.

26. Event Adapter • Event adaptors decouple the incoming event notifications from the listeners. • Event adaptors are placed in between source and the actual listeners to provide an additional policy in event delivery. • Typical use of event adapters are: • Implementing an event queuing mechanism between sources and listeners. • Acting as a filter. • Demultiplexing multiple event sources onto a single event listener.