在MIDP2.0裡，我們可以擺脫這樣的限制。它供給了新的GameCanvas，支撐新的按鍵處理模式：按鍵狀態字。
首先應用一個GameCanvas，結構函數參數suppressKeyEvents表現是否抑止keyPressed等按鍵事件，抑止的話會減少系統不必要的函數調用，帶來性能上的提高。然後，在線程每次循環的初始，應用GameCanvas.getKeyStates()方法得到系統的按鍵狀態。這個狀態字是一個int值，其中每一位表現一個按鍵是否是按下狀態。這樣既支撐了多按鍵，又完整不會搶用系統調用paint的時間，還在必定程度上提高了性能。
得到keyState之後，一般采用位運算來判定某鍵是否按下：
int keyState = getKeyStates();
if ((keyState & LEFT_KEY) != 0) {//假如左鍵按下
//處理代碼
}
else if ((keyState & RIGHT_KEY) != 0) {//假如右鍵按下
//處理代碼
}
通過位運算，還可以得到其他利益。比如，假如你記錄上次按鍵信息的話，那麼
newKeys=~lastKeyState&curKeyState; //上次檢測之後新按下的鍵，相當於keyPressed捕捉到的鍵
lostKeys=lastKeyState&~curKeyState; //上次檢測之後松開的鍵，相當於keyReleased捕捉到的鍵
changedKeys=lastKyeState^curKeyState; //轉變了狀態的按鍵
還有幾個要留心的標題：
假如當前GameCanvas不是正在顯示的Displayble對象，那這個方法總返回0。
當你在保持按鍵的時候將GameCanvas重新顯示在屏幕上時，getKeyState不會立即得到當前按下的鍵的信息，而是仍然保持為0，直到保持的按鍵松開再重新按下的時候，這時才可以得到准確的按鍵狀態信息。
目前Foma和Vodafone下許多程序的按鍵處理都是用MIDP1.0的keyPressed和keyReleased還有commandAction來做的。最近在VT603等新機型上測出來一個bug，軟鍵切換菜單或狀態時假如按下軟鍵不放，這個鍵將會不停的產生後果，最常見的就是游戲中Pause狀態的切換。初步猜測是系統主動實現軟鍵的持續按鍵，多次回調commandAction函數所致。
一個暫時的解決措施是把keyPressed、keyReleased改為keyPressedEx、keyReleasedEx，往除commandListener接口，把按鍵接收改為在每次線程刷新的初始主動查詢keyState，根據具體的位判定哪個按鍵按下，然後手動調用keyPressedEx、keyReleasedEx、commandAction函數。
留心：以後寫新游戲請大家盡量改為應用getKeyStatus的方法來處理按鍵。
Foma下按鍵狀態：
Canvas的getKeypadState()方法。此函數不像MIDP2.0的，不管canvas是否是當前正在顯示的canvas，都返回按鍵值。
返回的int共32位，第15位和16位為soft1和soft2。
其余鍵對應位參見文檔Display類。
Vodafone下按鍵狀態：
首先用DeviceControl.getDefaultDeviceControl()得到一個DeviceControl對象的實例dc。
然後調用dc.getDeviceState(DeviceControl.KEY_STATE)得到按鍵狀態。
返回的按鍵狀態值第17位和18位位soft1和soft2。
其余鍵對應位參見文檔DeviceControl類。
