Triggering UITableView's -didSelectRowAtIndexPath: delegate callback

[Carl Hoefs]

iOS 9.2

At certain times I need to update the data source for a table view. Then I cause the row that was updated to be selected using UITableView's -selectRowAtIndexPath::: method. That much works fine.

The problem is that the delegate callback associated with selecting that row doesn't occur. And indeed, I have since found that the documentation for this method says:

"Calling this method does not cause the delegate to receive a tableView:didSelectRowAtIndexPath: message."

Is there a method to call (or some other way) that will do this?
-Carl


_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

Thi

[Ben Kennedy]

Post by Carl Hoefs
"Calling this method does not cause the delegate to receive a tableView:didSelectRowAtIndexPath: message."
Is there a method to call (or some other way) that will do this?

Why not just call that method yourself?

b



_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This email sent t

[Carl Hoefs]

Post by Ben Kennedy

Post by Carl Hoefs
"Calling this method does not cause the delegate to receive a tableView:didSelectRowAtIndexPath: message."
Is there a method to call (or some other way) that will do this?

Why not just call that method yourself?

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];
-Carl


_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This email sent to g

[Ben Kennedy]

Post by Carl Hoefs
[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.

-ben


_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

This email sent to ge

[Luke Hiesterman]

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 <cocoa-***@esoteritech.com<mailto:cocoa-***@esoteritech.com>> wrote:


On Feb 27, 2016, at 3:59 PM, Ben Kennedy <***@zygoat.ca<mailto:***@zygoat.ca>> wrote:


On 27 Feb 2016, at 11:17 am, Carl Hoefs <***@autonomy.caltech.edu<mailto:***@autonomy.caltech.edu>> 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 (Cocoa-***@lists.apple.com<mailto:Cocoa-***@lists.apple.com>)

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:
https://lists.apple.com/mailman/options/cocoa-dev/luketheh%40apple.com

This email sent to ***@apple.com<mailto:***@apple.com>

_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.net

[Jens Alfke]

Post by Luke Hiesterman
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.

NSTableView doesn’t work that way. Changing the selection programmatically does not trigger a selection-changed notification / delegate callback.

—Jens
_______________________________________________

Cocoa-dev mailing list (Cocoa-***@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/gegs%40ml-in.narkive.