(Please note that the behavior described in this question only appeared because of something else seemingly unrelated we were doing. See the accepted answer.)
We have an Android activity with a GridView and a SlidingDrawer inside of a RelativeLayout. The way this activity responds to the trackball (or cursor keys) is rather odd. The focus will move among the items in the GridView, but whenever the cursor moves in a direction “out” of the GridView. (e.g. up when at the top, left when already at the leftmost item) the sliding drawer opens or shut. Notably, the focus stays on the same item in the GridView—it does not move to the sliding drawer.
With a trackball this is particularly horrible, as spinning the trackball past your real destination will cause the sliding drawer to repeatedly open and close.
We’ve determined that we can turn off the trackball entirely by overriding onTrackballEvent(). We’d prefer to have the trackball and cursor work normally on the GridView but not cause the sliding drawer to open or close. In principle we’d also like the trackball to focus on the various contents of the sliding drawer when it is open.
How?
As it turned out, we caused this problem by an unrelated bit of foolishness. We wanted the MENU key to open and close the
SlidingDrawer. We did this by overridingonPrepareOptionsMenu():This works fine; but it turns out it can be called when the menu is not about to be opened. In particular, if the
ActivityusessetDefaultKeyMode(DEFAULT_KEYS_SHORTCUT), then an unhandled key event will end up accessing the menu. This includes trackball motion off the edge of the screen.The less dumb way to get the desired behavior is
Meanwhile, we can get the trackball to move within the
SlidingDrawerwhen it is open by setting up aSlidingDrawer.OnDrawerOpenListenerwhich callsFinally it seems like a good idea to call