Question

In my activity I respond to an onClick() by replacing the current view with a new one (setContentView()). For some reason when I do this and then go back to the original view later the button I originally pressed still looks like it is pressed.

If you ‘refresh’ it somehow (e.g. scroll over it with the trackball) then it reverts to the unpressed state. It’s as if the button doesn’t get the ‘touch-up’ event.

The weird thing is: This only happens on my T-Mobile Pulse (android 1.5). It doesn’t happen on the emulator.

I’ve tried calling invalidate()/postInvalidate() on the view when I show it but it doesn’t have any effect.

Answer 1

My guess is that your “touch-up” event will go to your new content view.

You can either:

• Not call setContentView() at all in onClick(), using other means of achieving your UI aims (multiple activities, ViewFlipper, etc.).
• Not call setContentView() immediately in onClick(), but instead post() a Runnable that will call setContentView(). That should put the content view replacement in the event queue after the “touch-up” event.

Personally, I am not a big fan of activities constantly calling setContentView(), as I worry about memory leaks and overly-plump activities making state and memory management more difficult. For example, let’s say you call setContentView() for your original layout (A), then call setContentView() for your new layout (B), then the user rotates the screen. Android’s default onSaveInstanceState() will help you with B — hanging onto EditText contents and the like — but for A, you’re on your own.