Introduction to Java Beans CIS 421 Webbased Java

Introduction to Java Beans CIS 421 Web-based Java Programming Nov. 21, 2003 -BPU

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 – Bean. Box 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 v. Provides Information used by builder tool to customize the appearance and behavior of Beans. Run-time Environment v. 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 Public synchronized Foo. Listener add. Foo. Listener (Foo. Listener fel) fire Event Source e. Listener Interface reference Foo. Event [1] contd. . Register Listener Event Listener Class fooey implements Foo. Listner { Void foo. Bar. Happened (Foo. Event fe) { } }

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. – add. Action. Listener(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. event. Object § 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 Event. Object Compoent. Event Focus. Event Input. Event Mouse. Event

Semantic Events Action. Event Item. Event Adjustment. Event

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 Event. Object class.

Event Delivery § Events can be delivered as either unicast or multicast. – Unicast – Only one listener possible. ØThrows Toomany. Listeners. Exception – Multicast – Many listeners possible.

Adding an Event to the Bean § Create Event. Listener class. § Create Event. Listener objects in the bean. § Register the Event. Listener 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.