I'm trying to setup a UI with a UIPickerView that's populated based on the selected row in a UITableView. Essentially, it's the same UI you see in the Start & End screen for adding an event in the Calendar app.
http://raoli.com/files/uipicker.png
I've got my data source and delegate's setup so it the picker gets populated based on the selection and properly updates my model... most of the time.
The one hitch I'm getting is when somebody flicks the picker view and then changes the selection is in the table view, the UIPickerViewDelegate tries to records the changes against the new selection in the table view, not the original selection. It's obviously in my code why this happens and I have some ideas for reworking my to better behave, but I figured I'd see what Apple was doing in their UI.
When you flick the picker and switch the time before the picker finishes rotating, the rotation is immediately stopped, the picker updates to the value for the new type of time, and the original type of time remains unchanged. I'm not seeing any way to cancel the animation, but开发者_开发问答 I could be wrong. I hope I'm wrong, since it would make my life easier.
The other alternative I could see is different UIPickerViews for each attribute and switching them out. So, obviously, the Apple example would have 2 UIPickerView instance. That just creates other work that needs to be done and I thought I'd see if there was a way to do it with a minimal number of views.
Update Aaron's idea showed some promise, but it looks like there are a number of edge cases about how messages get delivered to the delegate based on the state of the picker, primarily whether or not the picker is currently animating. Since there seems to be no way to determine if the picker is currently spinning (at least via public APIs), trying to work around the possible configurations seemed problematic. I ended up going with multiple pickers, toggling the visibility of the pickers when the selected attribute changes, and ignoring delegate messages from now-hidden UIPickerView instances.
I think
- (void)selectRow:(NSInteger)row inComponent:(NSInteger)component animated:(BOOL)animated
would be a good candidate. If animated
is NO
it should display what you want immediately without moving.
When you decide the data is set, call the method on the picker view to reflect that setting. I expect it will override any current animation or inertia effect and hopefully you will not receive a didSelectRow:
in the delegate. If you do it might be necessary to ignore it.
精彩评论