Re: Triggering UITableView's -didSelectRowAtIndexPath: delegate callback
Re: Triggering UITableView's -didSelectRowAtIndexPath: delegate callback
- Subject: Re: Triggering UITableView's -didSelectRowAtIndexPath: delegate callback
- From: Luke Hiesterman <email@hidden>
- Date: Mon, 29 Feb 2016 00:55:41 +0000
- Thread-topic: Triggering UITableView's -didSelectRowAtIndexPath: delegate callback
It is a general design pattern of all of UIKit - not just UITableView - that delegate callbacks for user actions are not triggered when those same actions are done programmatically. If you’re going to file a bug, I suggest filing it on the entire UIKit design pattern.
Luke
On Feb 27, 2016, at 4:27 PM, Keary Suska <email@hidden<mailto:email@hidden>> wrote:
On Feb 27, 2016, at 3:59 PM, Ben Kennedy <email@hidden<mailto:email@hidden>> wrote:
On 27 Feb 2016, at 11:17 am, Carl Hoefs <email@hidden<mailto:email@hidden>> wrote:
Yes, that works, thanks! I just thought there might be a "preferred" way to do it. I guess I was hoping for something like:
[myTableView selectRowAtIndexPath:indexPath
animated:YES
scrollPosition:UITableViewScrollPositionMiddle
triggersDelegateCallback:YES];
What gain would that afford you, though?
I believe that the table view API is designed this way to afford the programmer control and flexibility. Perhaps your didSelectRow:... implementation calls some private method to do the business logic, say -[self fireTheRockets]. In that case, you could simply call fireTheRockets directly here instead.
By contrast, the delegate API provides your code a means to act on external events (user input) brokered by the table view. Perhaps in such a case there is additional UI-related work not suitable for inclusion in fireTheRockets.
This decoupling enables you to separate these concerns.
Except that it doesn’t follow. There is no design necessity that the object programmatically setting the selection is the same object as the delegate, nor that those two objects know anything about each other. Also if a delegate implements such a delegate call it is signaling that it needs to know every selection change regardless of how it is accomplished (since it has not way of knowing in advance how it was accomplished, unless you decide to couple the two objects). This results in a much more reliable and extensible decoupling since no other object should know those internal signaling mechanics and should have confidence that any other object interested in the selection will be dutifully notified. In fact, this is how NSTableView works. Why UITableView doesn’t, seems worthy of a radar.
Best,
Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"
_______________________________________________
Cocoa-dev mailing list (email@hidden<mailto:email@hidden>)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com<http://lists.apple.com>
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden<mailto:email@hidden>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden