views:

191

answers:

4

I set up my viewController to use the edit button in the way Apple recommends:

self.navigationItem.rightBarButtonItem = self.editButtonItem;

When the user taps the edit button, it causes the setEditing:animated: method to trigger. In this method, I add or remove a "new row" depending on the editing value (i.e. a row the user can tap to add a new item).

When the user swipes across a cell (while not in edit mode), it also calls the setEditing:animated:, which causes my code to add this "new row" incorrectly. It should only show this new row when the entire viewController is in edit mode (i.e. when the edit button is tapped).

How can I resolve this issue?

A: 

I have no idea what your "new row" is about, but you could attach your edit button to a helper method that sets a flag before calling setEditing, and there you can check if the said flag is set and behave accordingly. Then clear the flag at the end of the method.

Eiko
Isn't there a way to do this without overriding the edit button's behavior? I'd like to use Apple's recommendation if possible. (I clarified the question)
Senseful
Is adding the new row standard behavior anyway? I thought a "+" or "Add" button would be the consistent way to do this. If a user needs to press edit to add new items, this calls for lots of support mails. :-)
Eiko
@Eiko: see the Contacts app for adding an email/phone
Senseful
@Senseful: That editing is a complete change of a the view, but I see the point. I think a flag and a custom button is the way to go then.
Eiko
A: 

Senseful u have to override setEditing:animated: method. or even u can set flag in this method as Eiko has suggested.

or other way is

u implement custom naviagtion bar. in that case u need image of Navigation bar and 2 buttons above it. add target to that button and implement functionality as your need

Nirmit Patel
A: 

Use the UITableViewDelegate method tableView:willBeginEditingRowAtIndexPath:. From the documentation:

"This method is called when the user swipes horizontally across a row; as a consequence, the table view sets its editing property to YES (thereby entering editing mode) and displays a Delete button in the row identified by indexPath. In this "swipe to delete" mode the table view does not display any insertion, deletion, and reordering controls. This method gives the delegate an opportunity to adjust the application's user interface to editing mode. When the table exits editing mode (for example, the user taps the Delete button), the table view calls tableView:didEndEditingRowAtIndexPath:."

In tableView:willBeginEditingRowAtIndexPath:, set a flag that editing mode was triggered using swipe to delete. Then, in setEditing:animated:, check the flag to see if editing mode was triggered normally or using swipe to delete and perform some action based on that check. Lastly, reset the flag in tableView:didEndEditingRowAtIndexPath: so that the default action will be performed when the edit button is pressed.

Ethan Vaughan
A: 

If you implement tableView:willBeginEditingRowAtIndexPath: and tableView:didEndEditingRowAtIndexPath:, the behavior of the method calls will change...

It will no longer call setEditing:animated:, you must handle all editing change logic inside the above two methods. As a side effect of this, self.editing will no longer be YES when a swipe gesture is invoked. This is because the setEditing:animated: is responsible for setting self.editing = YES.

Senseful