The main description of this paper is what mechanism is in the end of the event transmission in J2ME development. The analysis and research is mainly analyzed by the serialization of the Canvas class event transmission, and the argument is carried out by an example and finally conclusions.
With reference to Java DOC, we can know that event transfer in J2ME is serialized, then what is serialization? The Java DOC said that after a time method call is completed, the following event method will be called. This ensures that the user's last input has been completed, and the next event input will be responded. First let's take a look at those methods are the so-called event methods. Listed in the MIDP follows: showNotify () hideNotify () keyPressed () keyRepeated () keyReleased () pointerPressed () pointerDragged () pointerReleased () paint () the CommandListener's commandAction () method for the above we serialized Understanding does not prevent this assumption, when the showNotify () method is called, if the repaint () method is defined internally, the system will be reroute to draw the screen, which is called to the Paint () method. Next we implement the keypressed () method, let it print the name of the button on the screen. In order to simulate the serialization effect, we make the current thread sleep 2000ms in each method. If the event is indeed a serialization mechanism, then the program will be intermittently drawing our button name. In order to demonstrate our idea, I wrote a piece of code below. 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 ()} (); 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 CANVAS is displayed on the screen, the showNotify () method is first called, and it is called after the repaint () method is called, not the screen will be drawn immediately. Instead, wait for two seconds, the shownotify () method returns, the Paint () method begins to execute. In these two seconds, even if you do not reactivate it, your button event will be cached to a queue, one is slowly drawn. Below is a screenshot of the program for reference
There is a note in the Java DOC of the Canvas class. There is some questions worthy of attention. For example, the servicerepaints () method will force any hangs to be implemented immediately, shownotify () and hidenotify () methods use some of the attention, readers, readers Further content can be found for Java DOC.
