• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Listeners vs. Low-level processing

 
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!
 
"The Hood"
Posts: 8521
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Cindy Glass
"The Hood"
Posts: 8521
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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).]
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic