Demonstrate the event Transmission Mechanism of j2_based on Instances

This article mainly describes the mechanism of event transmission in the Development of j2s. This article mainly analyzes and studies the serialization of Canvas event transmission, demonstrates the case through examples, and draws a conclusion at the end.

By referring to the Java doc, we can know that the event transmission in j2s is serialized. So what is serialization? In java doc, after a time method is called, the following event method will be called. This ensures that the user's last input has been completed, and the next event input will receive a response. First, let's take a look at the so-called event methods. The following methods are listed in MIDP:

Showpolicy ()
HideNotify ()
KeyPressed ()
KeyRepeated ()
KeyReleased ()
PointerPressed ()
PointerDragged ()
PointerReleased ()
Paint ()
The CommandListener's commandAction () method

Let's make this assumption based on the above serialized understanding. If the repaint () method is defined internally when the showNotify () method is called, the system is requested to redraw the screen, which calls the paint () method. Next we implement the keyPressed () method to print the key name on the screen. In order to simulate the effects of serialization, we make the current thread sleep for 2000 ms in every method. If the event is indeed a serialization mechanism, then the program will intermittently draw our button name. To demonstrate our ideas, I wrote the following code.

 

Import javax. microedition. midlet .*;

Import javax. microedition. lcdui .*;

Public class KeyCodes extends MIDlet

{

Private Display display;

Private KeyCodeCanvas canvas;

Public KeyCodes ()

{

Display = Display. getDisplay (this );

Canvas = new KeyCodeCanvas (this );

}

Protected void startApp ()

{

Display. setCurrent (canvas );

}

Protected void pauseApp ()

{

}

Protected void destroyApp (boolean unconditional)

{

}

Public void exitMIDlet ()

{

DestroyApp (true );

Yydestroyed ();

}

}

Class KeyCodeCanvas extends Canvas implements CommandListener

{

Private Command cmExit;

Private String keyText = "hello let's go! ";

Private KeyCodes midlet;

Public KeyCodeCanvas (KeyCodes midlet)

{

This. midlet = midlet;

CmExit = new Command ("Exit", Command. EXIT, 1 );

AddCommand (cmExit );

SetCommandListener (this );

}

Protected void paint (Graphics g)

{

System. out. println ("I am invoked! ");

G. setColor (0,255, 0 );

G. fillRect (0, 0, getWidth (), getHeight ());

If (keyText! = Null)

{

G. setColor (0, 0, 0 );

G. drawString (keyText, getWidth ()/2, getHeight ()/2, Graphics. TOP

| Graphics. HCENTER );

}

}

Public void showNotify ()

{

Repaint ();

Try

{

Thread. sleep (2000 );

}

Catch (InterruptedException e)

{

}

}

Public void commandAction (Command c, Displayable d)

{

If (c = cmExit)

Midlet. exitMIDlet ();

}

Protected void keyPressed (int keyCode)

{

KeyText = getKeyName (keyCode );

Repaint ();

Try

{

Thread. sleep (2000 );

}

Catch (InterruptedException e)

{

}

}

}

Compile and run. We can see that when the Canvas is displayed on the screen, the showNotify () method is called first, and its repaint () method is called, not the screen will be drawn immediately. Instead, it takes two seconds to run the paint () method after the showNotify () method returns. During these two seconds, even if the screen is not re-drawn, your button events will be cached in a queue and drawn one by one. The following is a program for your reference.

There is a note in the java doc of the Canvas class to illustrate some important issues. For example, the serviceRepaints () method forces any pending painting requests to be executed immediately, showNotify () and hidenoworkflow () for more information, see java doc.