2

I have a tableview with custom UITableViewCells, each row in the table has a UILabel, UISwitch and detail disclosure indicator.

I'm looking for the best method of capturing the UIControlEventChanged for the switch but I also need the NSIndexPath of the switch that changed to update Core Data.

I don't want the UISwitch as an accessory type either.

I've been googling this for hours and the solution that keeps popping up is to use

[switch addTarget:self action:@selector(switchTapped:) forControlEvents:UIControlEventChanged];

then in the switchTapped: method use the following to get the NSIndexPath

NSIndexPath *indexPath = [self.tableView indexPathForCell:(UITableViewCell *)[[sender superview] superview]];

Is there a better way of doing this? I already have UITableViewCell subclassed, can I put a method in this class to return the NSIndexPath for a given switch?

Thanks in advance for any help

Matt Price
  • 34,499
  • 6
  • 24
  • 33
  • But if the view hierarchy is changed at any point such as iOS updates this will fail. – Matt Price Mar 19 '12 at 14:48
  • Good point, you can walk up and find the first superview that is of type `UITableViewCell`. That will be very likely to fail. – wbyoung Mar 19 '12 at 14:56
  • Perhaps I don't understand your question fully... You've got a UISwitch in your custom UITableViewCell and the UITableViewCell handles the switch being changed. Is that what you're saying? Can't you then create a protocol and set whatever your tableViewController is to be the delegate for that cell? Can you post extra code to illustrate your problem a bit more? – Nick Bull Mar 19 '12 at 14:57
  • @NickBull I have it working using the above code. In cellForRowAtIndexPath: I have [switch addTarget:self action:@selector(switchTapped:) forControlEvents:UIControlEventChanged]; Then in switchTapped: I have the above code NSIndexPath *indexPath = [self.tableView indexPathForCell:(UITableViewCell *)[[sender superview] superview]]; to get the UITableViewCell which allows me to get the NSIndexPath for that cell. But I don't like the nested superview approach to find UITableViewCell and was after a better method – Matt Price Mar 19 '12 at 15:01
  • So all of these are in the same class? That's what I'm getting at. From what you've put, it looks like you are putting too much knowledge into one class. You need to split it up. Then you can get access to the information much easier without having to rely on going through the view hierarchy which is just asking for trouble. – Nick Bull Mar 19 '12 at 15:09

2 Answers2

3

I'll take another opportunity to link to my answer here - tags and view hierarchy walking are clunky, error prone and unnecessary, and I see them recommended all over the place in SO answers. You can find the index path of any control using its frame and the table view's indexPathForRowAtPoint: method.

Community
  • 1
  • 1
jrturton
  • 118,105
  • 32
  • 252
  • 268
-1

Setting a proper tag for the switch in each row of the table is a feasible solution. Set the tag according to the indexpath of the row in which it is present.

That way you avoid the possible problems that might arise to changes in view hierarchy.

This post might also help you.

Community
  • 1
  • 1
Bourne
  • 10,094
  • 5
  • 24
  • 51