How to get the indexpath.row when an element is activated?

Question

I have a tableview with buttons and I want to use the indexpath.row when one of them is tapped. This is what I currently have, but it always is 0

var point = Int()
func buttonPressed(sender: AnyObject) {
    let pointInTable: CGPoint =         sender.convertPoint(sender.bounds.origin, toView: self.tableView)
    let cellIndexPath = self.tableView.indexPathForRowAtPoint(pointInTable)
    println(cellIndexPath)
    point = cellIndexPath!.row
    println(point)
}

Solution 1

giorashc almost had it with his answer, but he overlooked the fact that cell's have an extra contentView layer. Thus, we have to go one layer deeper:

guard let cell = sender.superview?.superview as? YourCellClassHere else {
    return // or fatalError() or whatever
}

let indexPath = itemTable.indexPath(for: cell)

This is because within the view hierarchy a tableView has cells as subviews which subsequently have their own 'content views' this is why you must get the superview of this content view to get the cell itself. As a result of this, if your button is contained in a subview rather than directly into the cell's content view, you'll have to go however many layers deeper to access it.

The above is one such approach, but not necessarily the best approach. Whilst it is functional, it assumes details about a UITableViewCell that Apple have never necessarily documented, such as it's view hierarchy. This could be changed in the future, and the above code may well behave unpredictably as a result.

As a result of the above, for longevity and reliability reasons, I recommend adopting another approach. There are many alternatives listed in this thread, and I encourage you to read down, but my personal favourite is as follows:

Hold a property of a closure on your cell class, have the button's action method invoke this.

class MyCell: UITableViewCell {
    var button: UIButton!

    var buttonAction: ((Any) -> Void)?

    @objc func buttonPressed(sender: Any) {
        self.buttonAction?(sender)
    }
}

Then, when you create your cell in cellForRowAtIndexPath, you can assign a value to your closure.

func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
    let cell = tableView.dequeueReusableCellWithIdentifier("Cell") as! MyCell
    cell.buttonAction = { sender in
        // Do whatever you want from your button here.
    }
    // OR
    cell.buttonAction = buttonPressed(closure: buttonAction, indexPath: indexPath) // <- Method on the view controller to handle button presses.
}

By moving your handler code here, you can take advantage of the already present indexPath argument. This is a much safer approach that the one listed above as it doesn't rely on undocumented traits.

Solution 2

My approach to this sort of problem is to use a delegate protocol between the cell and the tableview. This allows you to keep the button handler in the cell subclass, which enables you to assign the touch up action handler to the prototype cell in Interface Builder, while still keeping the button handler logic in the view controller.

It also avoids the potentially fragile approach of navigating the view hierarchy or the use of the tag property, which has issues when cells indexes change (as a result of insertion, deletion or reordering)

CellSubclass.swift

protocol CellSubclassDelegate: class {
    func buttonTapped(cell: CellSubclass)
}

class CellSubclass: UITableViewCell {

@IBOutlet var someButton: UIButton!

weak var delegate: CellSubclassDelegate?

override func prepareForReuse() {
    super.prepareForReuse()
    self.delegate = nil
}

@IBAction func someButtonTapped(sender: UIButton) {
    self.delegate?.buttonTapped(self)
}

ViewController.swift

class MyViewController: UIViewController, CellSubclassDelegate {

    @IBOutlet var tableview: UITableView!

    func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {

        let cell = tableView.dequeueReusableCellWithIdentifier("Cell", forIndexPath: indexPath) as! CellSubclass

        cell.delegate = self

        // Other cell setup

    } 

    //  MARK: CellSubclassDelegate

    func buttonTapped(cell: CellSubclass) {
        guard let indexPath = self.tableView.indexPathForCell(cell) else {
            // Note, this shouldn't happen - how did the user tap on a button that wasn't on screen?
            return
        }

        //  Do whatever you need to do with the indexPath

        print("Button tapped on row \(indexPath.row)")
    }
} 

Solution 3

UPDATE: Getting the indexPath of the cell containing the button (both section and row):

Using Button Position

Inside of your buttonTapped method, you can grab the button's position, convert it to a coordinate in the tableView, then get the indexPath of the row at that coordinate.

func buttonTapped(_ sender:AnyObject) {
    let buttonPosition:CGPoint = sender.convert(CGPoint.zero, to:self.tableView)
    let indexPath = self.tableView.indexPathForRow(at: buttonPosition)
}

NOTE: Sometimes you can run into an edge case when using the function view.convert(CGPointZero, to:self.tableView) results in finding nil for a row at a point, even though there is a tableView cell there. To fix this, try passing a real coordinate that is slightly offset from the origin, such as:

let buttonPosition:CGPoint = sender.convert(CGPoint.init(x: 5.0, y: 5.0), to:self.tableView)

Previous Answer: Using Tag Property (only returns row)

Rather than climbing into the superview trees to grab a pointer to the cell that holds the UIButton, there is a safer, more repeatable technique utilizing the button.tag property mentioned by Antonio above, described in this answer, and shown below:

In cellForRowAtIndexPath: you set the tag property:

button.tag = indexPath.row
button.addTarget(self, action: "buttonClicked:", forControlEvents: UIControlEvents.TouchUpInside)

Then, in the buttonClicked: function, you reference that tag to grab the row of the indexPath where the button is located:

func buttonClicked(sender:UIButton) {
    let buttonRow = sender.tag
}

I prefer this method since I've found that swinging in the superview trees can be a risky way to design an app. Also, for objective-C I've used this technique in the past and have been happy with the result.

Solution 4

Use an extension to UITableView to fetch the cell that contains any view:

---

@Paulw11's answer of setting up a custom cell type with a delegate property that sends messages to the table view is a good way to go, but it requires a certain amount of work to set up.

I think walking the table view cell's view hierarchy looking for the cell is a bad idea. It is fragile - if you later enclose your button in a view for layout purposes, that code is likely to break.

Using view tags is also fragile. You have to remember to set up the tags when you create the cell, and if you use that approach in a view controller that uses view tags for another purpose you can have duplicate tag numbers and your code can fail to work as expected.

I have created an extension to UITableView that lets you get the indexPath for any view that is contained in a table view cell. It returns an Optional that will be nil if the view passed in actually does not fall within a table view cell. Below is the extension source file in it's entirety. You can simply put this file in your project and then use the included indexPathForView(_:) method to find the indexPath that contains any view.

//
//  UITableView+indexPathForView.swift
//  TableViewExtension
//
//  Created by Duncan Champney on 12/23/16.
//  Copyright © 2016-2017 Duncan Champney.
//  May be used freely in for any purpose as long as this 
//  copyright notice is included.

import UIKit

public extension UITableView {
  
  /**
  This method returns the indexPath of the cell that contains the specified view
   
   - Parameter view: The view to find.
   
   - Returns: The indexPath of the cell containing the view, or nil if it can't be found
   
  */
  
    func indexPathForView(_ view: UIView) -> IndexPath? {
        let center = view.center
        let viewCenter = self.convert(center, from: view.superview)
        let indexPath = self.indexPathForRow(at: viewCenter)
        return indexPath
    }
}

To use it, you can simply call the method in the IBAction for a button that's contained in a cell:

func buttonTapped(_ button: UIButton) {
  if let indexPath = self.tableView.indexPathForView(button) {
    print("Button tapped at indexPath \(indexPath)")
  }
  else {
    print("Button indexPath not found")
  }
}

(Note that the indexPathForView(_:) function will only work if the view object it's passed is contained by a cell that's currently on-screen. That's reasonable, since a view that is not on-screen doesn't actually belong to a specific indexPath; it's likely to be assigned to a different indexPath when it's containing cell is recycled.)

EDIT:

You can download a working demo project that uses the above extension from Github: TableViewExtension.git

Solution 5

Solution:

You have a button (myButton) or any other view in cell. Assign tag in cellForRowAt like this

cell.myButton.tag = indexPath.row

Now in you tapFunction or any other. Fetch it out like this and save it in a local variable.

currentCellNumber = (sender.view?.tag)!

After this you can use anywhere this currentCellNumber to get the indexPath.row of selected button.

Enjoy!

View more solutions

Comments

[Vincent]

should I use IndexPathForSelectedRow() instead of the point variable? or where should I use it?

[Dave G]

Antonio, I have a custom cell and would love to do this your way. However, it is not working. I want my 'swipe to reveal delete button' code to run, which is the tableView commitEditingStyle method. I removed that code from the mainVC class and put it in the customCell class, but now the code no longer works. What am I missing?

[jaytrixz]

Deleted my answer as it's the same with yours. I suggest an edit to the answer above without the ugly if let statements to let cell = view.superview.superview as! <Your custom cell name here>

[Jacob King]

The if let statements are there to prevent the app from crashing should any of the superviews be nil, this is the correct way to unwrap and should not be considered 'ugly'.

[Jacob King]

itemTable is the name of my previously declared UITableView

[Jacob King]

This is a nice way of doing it, and I will upvote it to get your rep started a bit, however the only flaw is it doesn't give access to the indexPath.section if this is also needed. Great answer though!

[Iron John Bonney]

Thanks Jacob! I appreciate the rep karma. If you wanted to get the indexPath.section in addition to the indexPath.row (without resetting the tag property as indexPath.section), in cellForRowAtIndexPath: you could just change the tag to button.tag = indexPath, and then in the buttonClicked: function you could access both by using sender.tag.row and sender.tag.section.

[Jacob King]

Is this a new feature, because I'm sure I remember the tag property being of type Int not type AnyObject, unless that changed in swift 2.3?

[Iron John Bonney]

@JacobKing you're right! My bad I totally spaced when writing that comment and was thinking that tag was type AnyObject. Derp - don't mind me. It would be useful if you could pass the indexPath as a tag though...

[mattyU]

hum this is embarrassing because i spent a lot of time trying to figure it out, but it might be useful for some people : "button" is an @IBOutlet UIButton that has to be created in the TableViewCell. And finally and in cellForRowAtIndexPath : cell?.button.tag = indexPath.row cell?.button.addTarget(self, action: "buttonClicked:", forControlEvents: UIControlEvents.TouchUpInside)

[Swayambhu]

indexPathForCell will return type of NSIndexPath. so the var indexPath should not be Int! it should be var indexPath: NSIndexPath!

[Jacob King]

Well spotted. I am a competent developer, I promise ;) - Have amended my answer.

[OOProg]

What does it mean if the error runs? What are some reasons why it can't find the point in the tableView?

[Paulw11]

buttonTapped is the delegate function and is in the view controller. In my example, someButtonTapped is the action method in the cell

[Bhavin Bhadani]

@paulw11 I got cell has no member buttonTapped in this method @IBAction func someButtonTapped(sender: UIButton) { self.delegate?.buttonTapped(self) }

[Paulw11]

Your cell shouldn't be it's own delegate. The view controller is the delegate

[Paulw11]

Check your code - it should say weak var delegate: FollowingCellDelegate? not weak var delegate: FollowingCell? = nil Also since the delegate is optional there is no need to explicitly assign nil

[rmaddy]

This is not the proper way to get the cell from a button. A cell's layout has changed over the years and code like this will fail to work when that happens. Do not use this approach.

[rmaddy]

This will not work. The button's superview will not be the cell.

[bpapa]

This is a bad solution. It assumes details about UITableViewCells that Apple has never necessarily agreed to. While UITableViewCells have a contentView property there is no guarantee that the contentView's superview will always be the Cell.

[bpapa]

Not really a good approach either. For one thing, it would only work in Table Views where there is a single section.

[bpapa]

This is a pretty good solution (nowhere near as bad as the two currently with more votes, using the tag looking at the superview) but it feels like too much extra code to be adding.

[bpapa]

This (or similar, using the UIView Converting methods) should be the accepted answer. Not sure why it's currently #4, as it doesn't make assumptions about a table view's private heirarchy, it doesn't use the tag property (almost always a bad idea), and doesn't involve a lot of extra code.

[Robotic Cat]

This is the correct solution and should be the accepted answer. It does not abuse the tag property, does not assume the construction of cells (that can easily be changed by Apple) and will still work (with no extra coding) when cells are moved or new cells added in between existing cells.

[Paulw11]

@bpapa there isn't too much extra code here. You would need to write code to handle the tap anyway, so the "extra" code is 3 lines of protocol definition, 1 line for the delegate property, 1 to set it, 1 to clear it and 1 to invoke it, however I do like the closure answer too.

[bpapa]

Protocol, delegate, complexity, etc. I've always used the "locate the button in the scroll view" method described, 2 lines.

[Jacob King]

@bpapa I did make a point of saying this in the answer, it's not like I didn't make the OP aware...

[Iron John Bonney]

@bpapa That's correct, using the tag property only returns the row, so it only works for a single section. I just updated the answer to provide a way to grab the indexPath, so that you can use it with a multi-section tableView.

[Sean]

This does work. The only thing you should be carefully of is that everyone's view stack is different. It could be sender.superview, sender.superview.superview or sender.superview.superview.superview. But it works really well.

[Edward]

I think this is the best way to get the indexPath of a cell with x sections, however I don't see the need for bullet points 3 and 4 in a MVC approach

[Adrian]

@Paulw11 I initially thought this was a lot of code, but it's proven a lot more resilient than what I was using before. Thank you for posting this robust solution.

[Karishma]

This is the best solution I have found so far! Thank you so much!

[Jeremy Andrews]

Thanks I used the extension to get the indexPath of a textview in a cell - worked perfectly.

[Pintu Rajput]

if let cell = sender.superview?.superview as? UITableViewCell { } is not working for me.

[Jacob King]

@PintuRajput Can you describe your view hierarchy to me please? You're likely seeing this because your button is not a direct subview of the cell's content view.

[Pintu Rajput]

@JacobKing Done :(

[Erick Maynard]

This solution also assumes the button pressed isn't nested within any other views.

[CW0007007]

Traversing superviews is a very bad idea.

[ymutlu]

This is the correct solution and should be the accepted answer.

[ymutlu]

This answer is like a joke. You should not use superview to reach parent views. This could break with any minor update in view hierarchy

[Jacob King]

@ymutlu I totally agree, I did state this in the answer. I also proposed a much more robust solution. The reason I left the original in place is because I feel it's better to show other devs the issues with an approach than dodge it altogether, this teaches them nothing you see. :)

[10000RubyPools]

Cleanest answer, should be the selected. Only thing to note is that tableView is an outlet variable that needs to be referenced prior before this answer working.

[Duncan C]

This is a good clean solution but it requires a lot of setup. I prefer my solution of adding an extension to UITableView. (See my answer.)

[Bhavesh.iosDev]

i think delegate property should be weak otherwise it create retain Cycle.

[Amalendu Kar]

Most appropriate answer

[Parthpatel1105]

Work like charm!!

[Wangdu Lin]

Good answer! Best for me

[finalpets]

Nice Solution just Change : swift tableView.indexPathForCell(cell) for swift tableView.indexPath(for: cell)

[Duncan C]

That approach works, but view tags are fragile, as mentioned in my answer. A simple integer tag won't work for a sectioned table view, for example. (an IndexPath it 2 integers.) My approach will always work, and there's no need to install a tag into the button (or other tappable view.)

[koen]

No, tags will be off when the user adds or removes cells.

[mramosch]

@koen: Not if you reload the tableView after inserting or deleting ;-)

[mramosch]

You can easily store the section and the row/item in one Integer. See my answer...

[mramosch]

You can easily store the section and the row/item in one Integer. See my answer...

[Rakshitha Muranga Rodrigo]

Way to go. Thanks... The point is @objc func btnCheck(_ sender: UIButton) set as the addTarget to the button inside cell and setting button tag accordingly.

[Ravi]

Worked like a charm!!

[Uday Kumar Eega]

This worked well as per my needs. Thanks man.