0

I have a situation where my UIPickerView is getting "starved" by a computation task; in other words, the UIPickerView is never updated -- and hence, never sends messages -- because a very heavy compute task is happening. The picker controls aspects of the computation, so the two have to play nice.

I thought of running the computation in a separate thread. Seems like that would leave the picker free to update. However, it'd be a massive undertaking to make my computation multithread-able, so I'd like to find another solution.

Is it possible for a picker (or other UI controls) to "preempt" the execution of a block of code? The computation is in a loop; the number of iterations is what makes it heavy. If the picker could even set a flag somewhere, the loop could break itself, which would work with the flow of the program.

If the loop could poll the picker, that would also work. But, I haven't found a way to do that.

Ideas?

(ps. I posted a similar question yesterday, but didn't really ask it correctly -- didn't quite know what the problem was at that time!)

Anna Dickinson
  • 3,307
  • 24
  • 43

1 Answers1

0

I assume you mean by flag that if the picker is moved, set a flag. If so you can do this - look at the picker delegates, and when any or all of them get called, set a flag. If your computation is done by another class or classes, then create a new property on those classes "cancelled", the picker can set it, and when set the computation ends.

Before you start another computation you would clear that cancel flag, then kick off the computation.

You can also put a simple toolbar above the picker (common practice) where you have controls that could start the computation, show progress, and cancel it.

EDIT: if the issue is the picker is stuttering when the user is trying to manipulate it, then subclass UIPicker, intercept touch events, and while the picker is being touched, cancel all computations. The only complication is that if the user "spins" the picker, you'd want to wait til it settles, but you would not know how long to wait. Depending on the last touch message, you would have to use a heuristic to wait for didSelectRow: or a timeout before restarting the computation.

David H
  • 40,852
  • 12
  • 92
  • 138
  • That would be a good idea, but... the problem is that the picker didSelectRow delegate (which is the only action message, I think) never gets called; basically, the picker is being starved for cycles. I don't understand, though, how that would happen. I would think the timer (or whatever it is) which updates the picker would queue the messages. So, it might update late, but eventually. Doesn't quite make sense... – Anna Dickinson Aug 21 '12 at 22:15
  • Did you set the delegate? Are you 100% sure you set the delegate to your class and it didn't get reset by another object? Even if you do lots of work on the main thread you should be getting delegate methods at some point. – David H Aug 21 '12 at 22:43
  • Yes, the delegate works -- it's just late. Something about the computation is delaying it -- and *just* it. As a test, I created a button and placed it in the same super-view. The message from the button can interrupt the computation just fine. And, after the button's message is processed, the picker is updated as well. Can you think of anything which would specifically delay just the picker? – Anna Dickinson Aug 21 '12 at 23:28
  • What you would need to do to really drill down on this is probably something you don't want to do. Subclass and add lots of UIView methods to see what's going on. The picker manages views - its not really a view subclass. So its doing a lot of messaging probably on the main runloop. The real solution to your problem is to run the computations in a block on a dispatch queue off the main thread (such an architecture also lets you use a cancel flag as long as its __block). – David H Aug 22 '12 at 00:32
  • Another idea - in the dataSource calls - where you are suppose to return values - add a log at the top of the call, and if you are doing any serious computation in that routine, log at the end. Also, can you clarify exactly what is slow about the picker? When you press a button, it fires immediately, so it got the touch events immediately. Is the picker not responding to touch events (ie you try to drag a cylinder up or down?). Is it just the delegate response that a row was selected that is slow? – David H Aug 22 '12 at 11:30
  • It's the wheel turning (it stutters), settling on the value, and sending the didSelectRow message. Fortunately, I *did* manage to find a rather inelegant workaround using the dataSource calls. The titleForRow message *does* arrive on-time. When the wheel moves, titleForRow is almost always called. (the key word being "almost," but...) So, I'm using that as the interrupt. Kinda messy, but from the user perspective, it ultimately means that you can mess with the wheel and get it to do *something*. Thanks! – Anna Dickinson Aug 22 '12 at 12:59