Because if it is animating, you don't want it to disappear and stop working
until the animation is done. You are absolutely not supposed to just leave
an animation attached to a view. Views that are currently animating are in
a special state, and have a lot of special behavior applied to them while
doing so.
On Tue, May 24, 2011 at 1:03 AM, Anm andrew.n.marsh...@gmail.com wrote:
Okay, so what is the rationale behind the animation null check? Why
would a view that is either GONE or INVISIBLE receive events just
because its animating (or more correctly, has a reference to a
Animation object, regardless of whether it is actively animating)?
Nothing I see in the Animation interface influences the view's
visibility state directly.
In the current code, we left animation objects attached to views to we
could reuse them. Instead of setting the reference to null, we had
set the Animation startTime to Long.MAX_VALUE, and later called
start(). This also avoided a invalidate/reset cycle for views that
were always the same size.
On May 23, 3:24 pm, Dianne Hackborn hack...@android.com wrote:
If you are receiving down events, then the view is almost certainly not
set
to GONE or it is still animating. The code for this part of dispatching
in
ViewGroup is pretty simply, and just immediately skips any non-visible
views:
for (int i = childrenCount - 1; i = 0; i--) {
final View child = children[i];
if ((child.mViewFlags VISIBILITY_MASK) !=
VISIBLE
child.getAnimation() == null) {
// Skip invisible child unless it is
animating.
continue;
}
So be sure the view is actually gone, and that you haven't left an
animation
in it.
On Mon, May 23, 2011 at 1:31 PM, Anm andrew.n.marsh...@gmail.com
wrote:
This morning, I'm trying to animate the various state of a simple
game. I have a transparent cover ViewGroup with a start and other
buttons. When the user hits start, the entire cover animates away.
At the end of the animation, I set the cover View to GONE which looks
correct, but the start button is still grabbing touch events instead
of the game's view. I had to manually iterate over all the start
button and other views within the cover to setClickable( false ) and
setEnabled( false ) (not sure if both were really needed) before I
started receiving my touch events again on the layers below the GONE
ViewGroup.
On May 23, 12:33 pm, Justin Anderson magouyaw...@gmail.com wrote:
I have never run into this... What situations have you come across
where
this happens?
Thanks,
Justin Anderson
MagouyaWare Developerhttp://sites.google.com/site/magouyaware
On Mon, May 23, 2011 at 1:13 PM, Anm andrew.n.marsh...@gmail.com
wrote:
This is something that I've run into a couple of times, and I'm
just
curious about the thought process behind such design, if
intentional:
When a view has visibility GONE, it is still allowed to accept UI
events. This is especially strange in positional UI events like
touch, where any positional state it likely an artifact of past/
invalidated state.
My colleagues and I cannot come up with any scenario where this
behavior would be desirable. Quite the opposite, it would seem to
be
an easy way to limit the view tree traversal for event handling.
Any insight would be greatly appreciated.
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to
android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to
android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--
Dianne Hackborn
Android framework engineer
hack...@android.com
Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see
and
answer them.
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
