Demonstrating the event transmission mechanism of J2ME through an example

This article mainly elaborated the question is, in J2ME development the event transmission exactly is what mechanism. This paper mainly focuses on the analysis and research of the serial of canvas event transmission, and proves it through an example and concludes at the end.

By referencing Java Doc We can know that the event transmission in J2ME is serialized, so what is serialization? Java Doc says the following event method is invoked when a time method call completes. This ensures that the user's last input has been completed and the next event entry will be answered. First, let's look at what these methods are called event methods. The following methods are listed in MIDP:

Shownotify ()
Hidenotify ()
Keypressed ()
Keyrepeated ()
Keyreleased ()
Pointerpressed ()
Pointerdragged ()
Pointerreleased ()
Paint ()
The Commandlistener ' s Commandaction () method

Our understanding of the above serialization does not make the assumption that when the shownotify () method is invoked, if the repaint () method is defined internally, the system is requested to repaint the screen, which calls to the paint () method. Next we implement the Keypressed () method and let it print the name of the key on the screen. To simulate the effect of serialization, we make the current thread sleep 2000ms in each method, and if the event is indeed a serialization mechanism, then the program will definitely draw our key names on and off. To demonstrate our vision, 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);

Notifydestroyed ();

}

}

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, run. We see that when the canvas is displayed on the screen, the Shownotify () method is invoked first, and its repaint () method is invoked, not immediately after the screen is drawn. Instead of waiting for two seconds, the paint () method begins execution after the Shownotify () method returns. In this two-second time, even if you press the button screen will not be redrawn, on the contrary, your key events will be cached to a queue, one by slowly drawing out. Here is a screenshot of the program for reference

A note in Java Doc for the canvas class describes some noteworthy issues, such as the Servicerepaints () method that forces any pending painting requests to be executed immediately, shownotify () and the Hidenotify () method uses some attention, etc. Readers can refer to Java Doc for further information.