Command Handling in MIDlets on T610 and Z600

t610은 softkey를 keyPressed에서 catch할 수 없기 때문에   Command를 이용해야 한다.   그런데 자꾸 application 에러가 나와서 다음 기사를 찾게 되었다.   요약하면 softkey를 눌러서 commandAction이 호출되는데, t610이나 z600은 key를 queue에 넣기 때문에   commandAction이 여러번 호출될지도 모른다는 이야기이다.   ----------- November 2003 Command Handling in MIDlets on T610 and Z600

When deploying your MIDP application to the device and starting to test it, you may find that you sometimes get the message "application error" when navigating through your main menu. At first glance, especially when comparing the same actions with the emulator, you may think that there is something wrong with the phone. Usually this problem occurs due to the way the T610 and Z600 family of devices handles command input. All command events generated end up with a call to your implementation of commandAction( Command c, Displayable d ).The unique feature of T610 and Z600 devices is that the device actually queues commands that are sent in sequence, meaning that if your commandAction() implementation takes some time in carrying out a specific action, the device will queue up additional key presses and execute your commandAction() handler again as soon as it has returned from its current state. Thus, if your implementation of commandAction() does not expect to get called with the same command twice in a row, you might get unhandled exceptions. A simple example of how to end up in such a state is shown below: commandAction( Command c, Displayable d ) { if( c == m_okcmd  && displayable == firstCanvas ) {        statemachine1.doAction1();        //Free up some memory        statemachine1 = null;        statemachine2 = new StateMachine2();        myDisplay.setCurrent( secondCanvas );     } } The example above will generate an unhandled NullPointerException if you press the key associated with m_okcmd twice in quick succession. The reason is that the parameters passed to the commandAction()  the second time will be the same as the first time it was called, so the first if() block will be executed twice. Since the code in the if() block has already been executed once, the statemachine1 variable will be set to null in order to save some precious memory. This will then lead to an unhandled exception. In order to discover errors like this, you can either try the on-device debugging feature of the Sony Ericsson device, or you can use a more basic "printf-debugging" style. In both cases you need the Sony Ericsson J2ME SDK 1.x. If you modify the sample as shown below, you will have a basic start in handling the errors and finding out where they occurred. commandAction( Command c, Displayable d ) {  try {     if( c == m_okcmd  && displayable == firstCanvas ) {               statemachine1.doAction1();               //Free up some memory               statemachine1 = null;               statemachine2 = new StateMachine2();               myDisplay.setCurrent( secondCanvas );         }    }    catch( Throwable t ) {         t.printStackTrace();    } } After making this change, download the application to the device, connect it to a serial interface (Bluetooth, IR etc), and launch the Device Explorer application in the Sony Ericsson J2ME SDK. Run the MIDlet, and perform the action that usually causes an "application error" message to be displayed. If the error is generated, you should see some output in the Device Explorer window on your PC, and also a stack trace of where the error occurred.