Yes, Java ME VMs may not call it and the simple tip here is to not rely on keyReleased at all.
One exception, however, is when you have a very closed set of target devices and can do manual tests on all of them.
Do I need to say to NOT trust an emulator execution?
Even in this situation, when would you use keyReleased instead of keyPressed?
Lets say you have a very nice custom UI with buttons, where they can be in one of the following states:
- Unselected: focus is not at this UI element
- Selected: got focus
My personal experience is that the pressed state is hard to perceive because users do not care about it.
They want to get things done. The faster the better.
So, instead of wasting jar size with code (or worst, images!) to draw a pressed state, run everything you need from keyPressed alone.
Of course, there are other usages of keyReleased, for example, one-button-games (OBGs), where the time between the key press and the key release might be very important to the game mechanics.
But even in these cases we can use only key press.
Most OBGs only have two states:
- Doing: jump, fire, turn, whatever
- Not doing
And the time doing is measured with the time between a key press and a key release.
To use only key presses at this situation you have to start the doing/action with a press and keep doing/acting until another press happens.
The change to the game mechanics is subtle and you can reach more devices with less code changes.
I had to review some of my components that relied on keyReleased to stop a key repetition, so can you.