Introduction to Java Beans

ITDC0205
Web-based Java Programming
 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.
 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
 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.

 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.

 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.

 Java Beans contd..

Features that distinguish a Java Bean from Java objects are:

– introspection

– customization

– externally occurring events

– properties

– persistence
 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
 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.
 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.
 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.
 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.
 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
 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
 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.
 Delegation Event Model [1] contd..

Public synchronized FooListener

Register Listener
addFooListener (FooListener fel)

fire Event Event

FooEvent Listener
Event Source

eListener
Class fooey implements FooListner {
Void fooBarHappened (FooEvent fe) { }
Interface reference
}
 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.
 Java Event Libraries

▪ java.util.eventObject

▪ java.awt.event

▪ java.awt.dnd

▪ javax.swing.event
 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.
 Low-level Events

EventObject

CompoentEvent

FocusEvent InputEvent

MouseEvent
 Semantic Events

ActionEvent ItemEvent

AdjustmentEvent
 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
 User-defined events?

▪ Custom Events:
– Can create and define events.
User defined event objects extend the EventObject
class.
 Event Delivery

▪ Events can be delivered as either unicast or

multicast.

– Unicast – Only one listener possible.

Throws ToomanyListenersException

– Multicast – Many listeners possible.

 Adding an Event to the Bean

▪ Create EventListener class.

▪ Create EventListener objects in the bean.

▪ Register the EventListener objects with Swing or

AWT components.
 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.