I have a UITableViewCell
with UISwitch
as accessoryview of each cell. When I change the value of the switch in a cell, how can I know in which row
Accepted solution is a clever hack.
However why do we need to use hitpoint if we can utilize already available tag
property on UIView? You would say that tag can store only either row or section since its a single Int.
Well... Don't forget your roots guys (CS101). A single Int can store two twice-smaller size integers. And here is an extension for this:
extension Int {
public init(indexPath: IndexPath) {
var marshalledInt: UInt32 = 0xffffffff
let rowPiece = UInt16(indexPath.row)
let sectionPiece = UInt16(indexPath.section)
marshalledInt = marshalledInt & (UInt32(rowPiece) << 16)
marshalledInt = marshalledInt + UInt32(sectionPiece)
self.init(bitPattern: UInt(marshalledInt))
}
var indexPathRepresentation: IndexPath {
let section = self & 0x0000ffff
let pattern: UInt32 = 0xffff0000
let row = (UInt32(self) & pattern) >> 16
return IndexPath(row: Int(row), section: Int(section))
}
}
In your tableView(_:, cellForRowAt:)
you can then:
cell.yourSwitch.tag = Int(indexPath: indexPath)
And then in the action handler you would can:
func didToogle(sender: UISwitch){
print(sender.tag.indexPathRepresentation)
}
However please note it's limitation: row and section need to be not larger then 65535. (UInt16.max)
I doubt your tableView's indexes will go that high but in case they do, challenge yourself and implement more efficient packing scheme. Say if we have a section very small, we don't need all 16 bits to represent a section. We can have our int layout like:
{section area length}{all remaining}[4 BITS: section area length - 1]
that is our 4 LSBs indicate the length of section area - 1, given that we allocate at least 1 bit for a section. Thus in case of our section is 0, the row can occupy up to 27 bits ([1][27][4]), which definitely should be enough.
Tags, subclasses, or view hierarchy navigation are too much work!. Do this in your action method:
CGPoint hitPoint = [sender convertPoint:CGPointZero toView:self.tableView];
NSIndexPath *hitIndex = [self.tableView indexPathForRowAtPoint:hitPoint];
Works with any type of view, multi section tables, whatever you can throw at it - as long as the origin of your sender is within the cell's frame (thanks rob!), which will usually be the case.
And here it is in a UITableView Swift extension:
extension UITableView {
func indexPath(for view: UIView) -> IndexPath? {
let location = view.convert(CGPoint.zero, to: self)
return self.indexPathForRow(at: location)
}
}
A colleague suggested the following, which I made into a UITableView category:
+(UITableViewCell*)findParentCellForSubview:(UIView*)view
{
while (([view isKindOfClass:[UITableViewCell class]] == NO) && ([view superview] != nil))
view = [view superview];
if ([view superview] != nil)
return (UITableViewCell*)view;
return nil;
}
Still hackly - but it works.
in cellForRowAtIndexPath:
, set the tag
property of your control to indexPath.row