com.sun.midp.events

Adding a New Event Type to the MIDP Java Event System

1. First select the new event type ID to be next the highest one in midpEvents.h. Add the new event type ID to midpEvents.h
2. If the event is a native event and there a not enough fields in NativeEvent, add the required fields to both NativeEvent and MidpEvent midpEvents.h. Follow the generic naming scheme.
3. Implement an EventListener.

class MyListener implements EventListener {
    public boolean preprocess(Event event, Event waitingEvent) {
        // only one of these events should be in the queue at a time

        if (waitingEvent == null) {
            // let the event be put in the queue
            return true;
        }

        ... merge the new event into the waiting event ...

        // signal that this event should not be put in the queue
        return false;
    }

    public void process(Event genericEvent) {
        MyEvent myEvent = (MyEvent)genericEvent;

        ... process the event ...
    }
}

4. Add code to obtain a security token for the class that is going to register the event listenter or post an Java event. The code depends on if the class is optional or not. If the class to receive the security token is optional then the class must implement the ImplictlyTrustedClass interface and have a public no argument constructor and so an instance of the class can be loaded by name in the initializeInternalSecurity method of the MIDletSuiteLoader and be given a token. If the class normal part of MIDP it can just implement a static method that sets the classes security token if the token has not already been set and insert a call to this static method in initializeInternalSecurity.

Previous and Currently Implemented Thread Models

To speed up Java to Java events like repaints a Java level queue was introduced to avoid the any native method calls. Processing was in one thread and native methods were feed into the Java queue by another thread to avoid polling the native event queue. This boosted the repaint rate three fold.

To speed up native event response during continuous event activity, the thread switch that occurred to process a native event after it was read was eliminated. This was done by letting the Java queue processing thread read events in a non-blocking way after a it had processed the pending Java events. To avoid polling when the processing thread ran out of events to process the queue would sleep. Just before sleeping, the Java queue processing thread wakes up a separate thread that monitors the native event queue in a blocking fashion, wakes up the Java queue processing thread when a native event was available to be read and goes to sleep. This model is used by the real device implementation and will be used for Leap Frog.

Each system that wants to receive events implements an EventListener and registers the listener with the EventQueue for each event type to be received.