It's not a secret anymore!*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Listeners vs. Low-level processing Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Listeners vs. Low-level processing" Watch "Listeners vs. Low-level processing" New topic
Author

Listeners vs. Low-level processing

Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
Hi everyone -
I'm confused as to *why* one would use low-level processing instead of implementing listener interfaces? From what I can tell, there aren't any events that can't be handled by listeners. Is it just speed? I'm reading Bill Brogden's "Exam Cram" and Mugal's "A Programmer's Guide To Java Certification."
Please explain!!
Thanks!
Cindy Glass
"The Hood"
Sheriff

Joined: Sep 29, 2000
Posts: 8521
You are thinking too limited. In embedded systems, the chips that run your cell phone, thermostat etc, do not use the AWT for these reasons:


Why not the AWT?
The MIDP Expert Group decided not to subset the existing AWT and Project Swing classes for the following reasons:
The AWT is designed for desktop computers and optimized for these devices.
The AWT assumes certain user interaction models. The component set of the AWT is designed to work with a pointing device such as a mouse; however many handheld devices, such as cell phones, have only a keypad for user input.
While the AWT has a rich feature set, it is mainly desktop-based. Also, the feature set includes support for features not found on handheld devices. For example, the AWT has extensive support for window management, such as resizing overlapping windows. However, the limited display size of handheld devices makes resizing a window impractical. Therefore, the window and layout managers within the AWT are not required for handheld devices.
When a user interacts with an AWT-based application, event objects are created dynamically. These objects exist only until each associated event is processed by the system, at which time the object becomes eligible for garbage collection. The limited CPU and memory of handheld devices cannot handle this behavior.

Note the last paragraph. Therefore there is a low-level API to handle this.

The low-level API provides little abstraction. It is designed for applications that need precise placement and control of graphic elements and access to low-level input events. This API gives the application full control over what is being drawn on the display. The Canvas and Graphics classes implement the low-level API.
It is important to note that MIDlets that access the low-level API are not guaranteed to be portable because this API provides mechanisms to access details that are specific to a particular device.

I expect that there are more examples out there.

"JavaRanch, where the deer and the Certified play" - David O'Meara
Cindy Glass
"The Hood"
Sheriff

Joined: Sep 29, 2000
Posts: 8521
OOOO!! Just found another use for low-level processing! (Stole it from Jim Yingst in Advanced)
There is a class called Robot in the AWT. It allows you to "remote control" a GUI and can be used to automate testing or demonstrations.
From the API:

public class Robot
extends Object

This class is used to generate native system input events for the purposes of test automation, self-running demos, and other
applications where control of the mouse and keyboard is needed. The primary purpose of Robot is to facilitate automated testing
of Java platform implementations.
Using the class to generate input events differs from posting events to the AWT event queue or AWT components in that the
events are generated in the platform's native input queue. For example, Robot.mouseMove will actually move the mouse cursor
instead of just generating mouse move events.
Note that some platforms require special privileges or extensions to access low-level input control. If the current platform
configuration does not allow input control, an AWTException will be thrown when trying to construct Robot objects. For
example, X-Window systems will throw the exception if the XTEST 2.2 standard extension is not supported (or not enabled) by
the X server.
Applications that use Robot for purposes other than self-testing should handle these error conditions gracefully.

So like you can hook it up to your co-workers GUI and drive him NUTS!!!

How fun Got to go. Things to be tested you know . . .

[This message has been edited by Cindy Glass (edited February 28, 2001).]
[This message has been edited by Cindy Glass (edited February 28, 2001).]
 
 
subject: Listeners vs. Low-level processing