Analogue of android:filterTouchesWhenObscured for API level below 9

android, android-2.1-eclair, obscured-view

Solution

Turns out, there is no way of doing it. In Android prior to API level 9, there are two ways around the problem:

Remove listeners from the underlying views (in my case, I have about a dozen of them, which I would need to remove and then re-set after the overlay is made invisible again); or

Add an empty onClickListener (i.e. intercept the `click` event and do nothing on it) on the entire overlay - this is the way I'm handling it in my case.

Interestingly, the behavior of an obscured view receiving `click` events was reported as a bug in an earlier version of Android, but that bug was closed indicating that it's not a bug but an intended functionality instead (I can't see why anybody would want that functionality though). I suppose the `android:filterTouchesWhenObscured` attribute was added in level 9 to appease all the unhappy developers out there :)

Problem

Starting with API level 9, there's `android:filterTouchesWhenObscured` attribute and corresponding `setFilterTouchesWhenObscured` method on `ViewGroup`. For example, when a view has `onClickListener` set and another view obscures that view (e.g. an overlay panel, a toast, or anything else), then touches will not be passed to the obscured view - in my example, `onClick` will not be fired. However, this is not available in API level 7 - and for my project the requirement is Android 2.1 and above, which means I have to work with level 7. Is there an easy way around it? In level 7, this property is essentially hard-coded to FALSE. As a result, I get this strange behavior: on a view, I have a button. When pressed, another view slides into place, covering the view with the button. On this view, there's its own button, but it doesn't match the location of the button underneath. Therefore if the user touches the overlay panel in the location where the button underneath is, the `onClick` of that button is fired again - not what I want/need. What can I do to prevent `onClick` firing in this case? Thanks.

Original source