views:

167

answers:

1

Hi, I have disabled interactions in my primary view (which contains some subviews I use as buttons).

I keep this disabled while I have a secondary view up indicating network activity (loading data). When it is finished, I re-enable interactions in the primary view.

This is so the user isn't tapping those buttons while the network operation takes place.

Anyway, all seems well, but the if the user starts tapping buttons in the primary view, once the re-enable occurs those touch events (from the past few seconds) actually trigger. Not the touches-began, which highlights the buttons, but the functions called on the touches-ended. Its like its queued the whole time it was disabled and "races to catch up".

It is very bizarre, why would touch events be queued while the view has its user interaction disabled?

+2  A: 

It's hard to be confident of an answer here without seeing the code, but here is one idea:

If your network activity is synchronous, aka blocking, then it could be the case that the user's touches are queued before they get a chance to hit any of your code. If that's the case, then those touches won't be sent into your responder chain until the network activity finishes, and they'd never get a chance to "know" that you'd disabled interaction with those controls.

Here's one way you could help debug your situation: Add some debug NSLog statements in the top layer (what you call the secondary view) that's indicating network activity. Make sure the secondary view's frame is big enough to include those touches, and see if it logs the touches as soon as they happen. If not, my guess might be correct. If yes, well, you still get useful information - and you might be able to simply capture the touches at this level, instead of allowing them to queue up.

If this guess is correct, the least hacky fix I can think of would be make your network operations asynchronous.

If you don't want to do that, you could also try using an NSTimer to leave the network activity indicator up for a split second after the synchronous call completes. This way, your responder chain could clear out the queue of incoming touches, and ignore them if that's the desired behavior.

Tyler
+1 excellent insight. I was writing a long winded answer when yours popped up, and I immediately discarded it, because mine seemed ridiculously narrow-sighted in comparison. I'd up-vote yours more if I could.
Dave DeLong
Thanks, Dave! I hope it's useful for Michael.
Tyler
Thanks, I really don't know where the problem is here. Basically this is a background view that is disabled, and a modal window that indicates network activity. I disable the back first. It is an async load of XML data. As soon as the data loads, I am removing the modal window, and re-enabling interaction on the background.Anyway, I am definitely not getting ALL of the touches and the disable-interaction does seem to work for the most part. But if I tap repeatedly within < 1 second of the data completing load, code gets executed that is tied to the touches.I guess another question is,
Michael
if userInteractionEnabled=NO, should this be stopping all touches from being queued?
Michael